DE69827213T2

DE69827213T2 - Verfahren und Vorrichtung zur Erhöhung der Datenausgabe eines Geräts mit eingeschränkten Betriebsmitteln

Info

Publication number: DE69827213T2
Application number: DE69827213T
Authority: DE
Inventors: James Gordon Auburn Wendt; James Eugene Meridian Clough; John David Rocklin Beninga
Original assignee: Hewlett Packard Development Co LP
Current assignee: Hewlett Packard Development Co LP
Priority date: 1997-09-18
Filing date: 1998-08-27
Publication date: 2006-02-02
Anticipated expiration: 2018-08-28
Also published as: DE69827213D1; JPH11154127A; US6067558A; EP0903675B1; EP0903675A1

Description

Die Erfindung bezieht sich auf elektronische Netzwerke. Insbesondere bezieht sich die Erfindung auf ein Verfahren und eine Vorrichtung zum Bereitstellen eines vergrößerten Inhalts von einer ressourceneingeschränkten Vorrichtung.
Mit dem explosionsartigen Wachstum des Internets ist es für Computerbenutzer und Netzwerkadministratoren erforderlich, dass sie in der Lage sind, auf Systeme über einen Browser des World Wide Web (Web) zuzugreifen und dieselben zu verwalten. Die graphischen Schnittstellen, an die sich Benutzer gewöhnt haben, erfordern große Datenspeicherungsmengen. Systeme, die große Plattenspeicherungsmengen haben, sind in der Lage, diese Informationen dem Benutzer direkt zu präsentieren.
Eingebettete Systeme, wie z. B. Drucker und andere Peripheriegeräte, weisen üblicherweise weniger Datenspeicherungskapazität auf. Dieser Mangel an Kapazität schränkt den Inhalt ein, den solche eingebetteten Vorrichtungen direkt dem Benutzer bereitstellen können. Als eine Folge dieses Mangels an Speicherungskapazität müssen solche eingebetteten Vorrichtungen einem Benutzer eine weniger elegante, nichtintuitive Schnittstelle präsentieren, z. B. eine Schnittstelle, die textmäßig mit wenigen graphischen Bildern präsentiert wird. Dies kann beim Benutzer Verwirrung verursachen, darüber, wie auf Informationen auf der Vorrichtung zugegriffen wird und wie die Vorrichtung konfiguriert wird.
Es wäre vorteilhaft, eine Technik bereitzustellen, die ermöglicht, dass eine ressourceneingeschränkte, eingebettete Vorrichtung einem Benutzer einen vergrößerten Inhalt bereitstellt, wenn auf die Vorrichtung zugegriffen wird, z. B. wenn die Vorrichtung eine allgemein akzeptierte Web-Browser-Metapher unterstützt.
Das Dokument „Scalable Web Server architectures" veröffentlicht im Verlauf des zweiten IEEE-Symposiums über Computer und der Kommunikation vom 1.–3. Juli 1997, Seiten 12–16 (ISBN 0-8186-7852-6), offenbart eine Webserverarchitektur, in der eine Hierarchie implementiert ist. Daten werden gemäß dem Inhalt partitioniert und in unterschiedlichen HTTP-Servern gespeichert. Umleitungsserver verteilen die Anforderungen von Benutzern zu dem relevanten HTTP-Server.
Das Dokument „HTTP, Java provide run-time control", veröffentlicht in Electronic Engineering Times Nr. 926, November 1996 (XP00 2075445), offenbart, dass Java verwendet werden kann, um eine eingebettete Vorrichtung mit dem Internet für einen Zugriff und eine Steuerung zu verbinden.
Das Dokument WO 96/42041 offenbart ein Verfahren zum Steuern und Überwachen von Zugriff auf Netzwerkserver. Ein Klient betrachtet ein Dokument innerhalb eines Browsers. Das Dokument ist im Hypertext-Format und umfasst Verknüpfungen zu anderen Hypertext-Seiten. Nach der Auswahl einer Verknüpfung übermittelt ein Server die Anforderung zu einem sekundären Server, der den Zugriff für den Klienten validiert.
Das Dokument „Java goes to work controlling network embedded systems", veröffentlicht in Computer Design, Bd. 35, Nr. 9, August 1996, Seiten 36–37 (XP 000631206) offenbart ein Softwaremodul, das schnittstellenmäßig mit einem anderen Programm verbunden werden kann und einen Zugriff auf das Programm über einen Webbrowser über das Internet hinweg ermöglicht.
Gemäß einem Aspekt der vorliegenden Erfindung wird eine Vorrichtung geschaffen, um es ressourceneingeschränkten Vorrichtungen zu ermöglichen, mehr Inhalt zu präsentieren, wie in 1 spezifiziert ist.
Das bevorzugte Ausführungsbeispiel schafft einen HTTP-Umleiter, der das Problem des Bereitstellens einer hochentwickelten graphischen Benutzerschnittstelle für ressourceneingeschränkte eingebettete Vorrichtungen löst, durch Ermöglichen, dass solche Vorrichtungen dem Endbenutzer mehr Inhalt präsentieren, ohne die Daten lokal zu speichern. Diese Daten werden durch die Verwendung eines Inhaltsservers bereitgestellt, sowie die Ressourcen des Inhaltsservers, um dem Benutzer die Informationen zu präsentieren. Das Umleitungsschema hierin ermöglicht, dass die Masse des eingebetteten, vorrichtungsspezifischen Inhalts (z. B. HTML- und/oder JAVA-Applet-Dateien) auf einem Inhaltsserver vorliegen und nicht auf dem Peripheriegerät selbst.
Das bevorzugte Ausführungsbeispiel ermöglicht ferner, dass JAVA-Applets, die auf einem Inhaltsserver angeordnet sind, verwendet werden, um peripheriespezifischen Inhalt und Seiten zu implementieren. Die JAVA-Sprache ist attraktiv für eine solche Anwendung, da sie eine leistungsstärkere Programmierungsumgebung bereitstellt als HTML, zum Konstruieren von interaktiven Benutzerschnittstellenprogrammen und zum Auffrischen von Statusanzeigen. Das Verwenden der Ressourcen des Inhaltsservers ermöglicht daher, dass die ressourceneingeschränkte Vorrichtung dem Benutzer einen reicheren Inhalt präsentiert. Ferner kann eine Vorrichtung durch Verwenden des hierin offenbarten Umleiters ohne weiteres JAVA-Applets präsentieren, die mehr Speicher erfordern als lokal verfügbar ist, was zu einer wesentlichen Ressourcenleistungskraft führt.
Das bevorzugte Ausführungsbeispiel kann eine Funktionalität bereitstellen, die eine webbasierte Peripherieverwaltungslösung basierend auf JAVA-Applets und einen Erzeuger einer Benutzerschnittstelle (U) auf oberster Ebene, der auf einem Inhaltsserver angeordnet ist, unterstützt. Bei dem hierin offenbarten Schema laufen Hintergrundroutinen (d. h. Webserver) des Hypertext Transfer Protocol (HTTP) sowohl auf einer Peripheriegeräteschnittstelle als auch auf einem Hostmaschinen-Inhaltsserver. Webbrowserzugriffe auf die Peripheriegerät-HTTP-Hintergrundroutine für Peripherie- oder anderen Inhalt werden durch die Peripheriegerät-HTTP-Hintergrundroutine zu einem Inhaltsserver umgeleitet, wo die tatsächlichen Hypertext Markup Language (HTML-) oder JAVA Applet Dateien gespeichert sind. Die Peripheriegeräteschnittstelle erzeugt ferner HTML-Programmrohlingsdateien, um beim Umleiten von Zugriffen auf JAVA-Applets auf dem Inhaltsserver zu helfen.
Gemäß einem anderen Aspekt der vorliegenden Erfindung wird ein Verfahren gemäß Anspruch 10 geschaffen.
Vorzugsweise folgt der Browser den Verknüpfungen zu den Peripherieschnittstellen- und den Vorrichtungs-Seiten durch Erhalten von Adressen für Peripherieschnittstellen- und vorrichtungsspezifische Seiten.
Vorteilhafterweise sind die Peripherieschnittstelle- und die vorrichtungsspezifischen Seiten als Applet- und Klassen-Dateien implementiert, die auf dem Inhaltsserver gespeichert sind, wobei die Applet- und Klassen-Dateien in dem Browser laden und ausführen, und wobei die Applet- und Klassen-Dateien mit der Peripherieschnittstelle und dadurch mit der Vorrichtung kommunizieren.
Der Browser kann die Peripherieschnittstelle kontaktieren und die Peripherieschnittstelle kann den Browser unter Verwendung einer Informationsseitenumleitung umleiten.
Bei einem Ausführungsbeispiel kontaktiert der Browser den Benutzerschnittstellenserver an einer umgeleiteten Position, die die Verknüpfung enthält, die Verknüpfung weist den Benutzerschnittstellenserver an, die Peripherieschnittstelle von einer Umleitungsadresse zu kontaktieren und die Daten, die an der Adresse enthalten sind, zu der Peripherieschnittstelle weiterzuleiten, wodurch verursacht wird, dass eine Seite zu dem Browser von der Peripherieschnitt stelle gesendet wird, wobei die Seite eine Bezugnahme auf eine Applet-Datei enthält.
Vorzugsweise richtet die Applet-Datei-Bezugnahme einen Kontakt zu der Peripherieschnittstelle an der Umleitungsadresse ein, wodurch die Applet-Datei heruntergeladen wird, um die Funktionalität der Peripherieschnittstelle zu verbessern.
Der Browser lädt vorzugsweise die Applet-Datei aus einer Umleitungsposition auf dem Inhaltsserver herunter.
Der Browser kann mit der Peripherieschnittstelle kommunizieren, um erforderlichen Informationen wiederzugewinnen, sobald die Applet-Datei durch den Browser geladen wurde.
Der Schnittstellenerzeuger kann einen Programmrohlingsdateimechanismus umfassen, zum Auslösen eines Applet-Datei-Abrufs.
Bei einem Ausführungsbeispiel führt die Peripherieschnittstelle eines aus Token-Ersetzung an dem Körper der Programmrohlingsseite, wodurch der Einschluss von Konfigurations- und Identitäts-Informationen ermöglicht wird, die auf der Peripherieschnittstelle enthalten sind, und einer Zeichenfolgenverarbeitung durch, die Leerstellenersetzung und Escape-Umwandlung umfasst.
Die Ersatz-Token können einen aus einem vollständig qualifizierten Bereichsnamen und einem Basis-URL-Weg einer Hostsoftwareposition auf dem Systemserver umfassen; einem vollständig schnittstellenqualifizierten Bereichsnamen; eine Schnittstellen-MAC-Adresse; einer Schnittstellenmodellidentifiziererzeichenfolge; und einer Peripheriemodellidentifiziererzeichenfolge.
Der Benutzerschnittstellenerzeuger kann Informationen enthalten, die sich auf die Position der Applet-Dateien auf dem Inhaltsserver, die Höhe/das Gewicht des Applet-Bereichs, und ob der Applet-Dateiname kundenspezifisch erzeugt werden sollte, um Zeichenfolgen für die Peripherieschnittstelle oder den Vorrichtungstyp zu enthalten, beziehen.
Vorzugsweise ist der Benutzerschnittstellenerzeuger entworfen, um ein Applet aus einer Benutzerschnittstellenseite anzufordern, durch Platzieren einer Verknüpfung in der Benutzerschnittstellenseite, die die Adresse eines Peripherieschnittstellen-Programmrohlingserzeugers enthält. Die Adresse kann ferner einen Körperparameter enthalten, der in einem vollständigen Applet-Etikett vorliegt, das in die Programmrohlingsseite eingefügt werden soll, die durch die Peripherieschnittstelle zurückgesendet wird. Der Applet-Etikettentext kann jegliche Token umfassen, die von der Peripherieschnittstelle für den Benutzerschnittstellenerzeuger in die Programmrohlingsseite ersetzt werden sollen, wodurch eine Modifikation des Applet-Dateinamens oder – Verzeichniswegs verursacht wird.
Bei einem Ausführungsbeispiel ist der Browser wirksam, um die Programmrohlingsseite zu empfangen und verarbeitet das Applet-Etikett und erhält dann eine zugeordnete Applet-Datei. Der Mechanismus kann derart konfiguriert sein, dass der Browser eine Erhalten-Anforderung nach Applet-Dateiadressen zu der Peripherieschnittstelle durchführen muss und diese Anforderungen zu Adressen auf dem Inhaltsserver umleiten lassen muss.
Ein Applet-Etikettentext, den die Benutzerschnittstellen-Erzeugerverknüpfung zu dem Peripherieschnittstellen-Programmrohlingserzeuger weiterleitet, kann der Weg zu der Applet-Datei und der Name der Applet-Datei sein, wobei der Weg eine Anfangsumleitungskomponente enthält, die ungeändert in der Programmrohlingsdatei zurückgesendet wird und die zu dem Weg wird, der durch den Browser verwendet wird, wenn er die Applet-Datei erhält.
Eine eingebettete Hintergrundroutine auf der Peripherieschnittstelle kann eine Umleitung einer Anforderung durchführen, die einen spezifischen Anfangsumleitungsweg in der Anforderungsadresse enthält.
Das oder ein Applet kann Anforderungen an eine der Peripherieschnittstelle und der Vorrichtung stellen, um spezifische Operationen auszuführen, sobald der Browser das Applet wiedergewinnt und das Abspielen desselben startet. Vorzugsweise führt die Peripherieschnittstelle eine Umleitung aller Anforderungen entweder nach der Peripherieschnittstellenwurzel oder den Hompage-Adressen durch, wobei eine spezifische Homepage-Adresse in der Peripherieschnittstelle konfiguriert ist, wobei die Peripherieschnittstelle mit einem Statuscode und einer Positionsadresse antwortet, die vorkonfiguriert wurde, aber die einem Token-Ersatz unterzogen wird, wenn die Peripherieschnittstelle eine Anforderung nach der Peripherieschnittstellen-Homepage empfängt.
Ein Ausführungsbeispiel der vorliegenden Erfindung wird nachfolgend ausschließlich beispielhaft Bezug nehmend auf die beiliegenden Zeichnungen beschrieben, in denen:
1 ein schematisches Blockdiagramm ist, das ein Ausführungsbeispiel eines Web-Umleitungsmechanismus darstellt;
2 ein schematisches Blockdiagramm ist, das eine Vorrichtungsentdeckung, eine UI-Erzeugung auf oberster Ebene und einen Klientenbrowserabruf einer UI-Seite oberster Ebene gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zeigt;
3 ein schematisches Blockdiagramm ist, das einen Benutzer zeigt, der einer Verknüpfung auf einer Seite folgt, wobei ein Klientenbrowser den Peripherieschnittstellen-Programmrohlingserzeuger aufruft und eine HTML-Programmrohlingsdatei (z. B. zum Auslösen eines Abrufs von JAVA-Applet) gemäß einem Ausführungsbeispiel der Erfindung empfängt;
4 ein schematisches Blockdiagrammm ist, das einen Klientenbrowser zeigt, der ein JAVA-Applet mit HTTP-Umleitung abruft;
5 ein schematisches Blockdiagramm ist, das ein JAVA-Applet zeigt, das mit einer Peripherieschnittstelle und/oder Peripheriegeräten gemäß einem Ausführungsbeispiel der Erfindung kommuniziert;
6 ein schematisches Blockdiagramm ist, das einen Klientenbrowser zeigt, der auf einen Peripherieschnittstellen-Haupt-URL bzw. Wurzel-URL zugreift und zu einem UI-Erzeuger oberster Ebene gemäß einem Ausführungsbeispiel der Erfindung umgeleitet wird; und
7 ein schematisches Blockdiagramm ist, das einen Browser zeigt, der auf einen Peripherieschnittstellen-Haupt-URL zugreift und zu einer HTML-Homepage gemäß einem Ausführungsbeispiel der Erfindung umgeleitet wird.
Das bevorzugte Ausführungsbeispiel schafft einen HTTP-Umleiter, der das Problem des Bereitstellens einer hochentwickelten graphischen Benutzerschnittstelle für ressourceneingeschränkte, eingebettete Vorrichtungen löst, durch Ermöglichen, dass solche Vorrichtungen dem Endbenutzer mehr Inhalt präsentieren, ohne die Daten lokal zu speichern. Diese Daten werden durch die Verwendung eines Inhaltsservers geliefert, und der Ressourcen des Inhaltsservers, um dem Benutzer die Informationen zu präsentieren. Das Umleitungsschema hierin ermöglicht, dass die Masse des eingebet teten vorrichtungsspezifischen Inhalts (z. B. HTML- und/oder JAVA-Applet-Dateien) auf einem Inhaltsserver vorliegt und nicht auf der Peripherievorrichtung selbst.
Das bevorzugte Ausführungsbeispiel ermöglicht ferner, dass JAVA-Applets, die auf einem Inhaltsserver angeordnet sind, verwendet werden, um peripheriespezifischen Inhalt und Seiten zu implementieren. Die JAVA-Sprache ist attraktiv für eine solche Anwendung, da sie eine leistungsstärkere Programmierungsumgebung bereitstellt als HTML zum Aufbauen von interaktiven Benutzerschnittstellenprogrammen und zum Auffrischen von Statusanzeigen. Das Verwenden der Ressourcen des Inhaltsservers ermöglicht daher, dass die ressourceneingeschränkte Vorrichtung dem Benutzer einen reicheren Inhalt präsentiert. Ferner, durch Verwenden des hierin offenbarten Umleiters, kann eine Vorrichtung ohne weiteres JAVA-Applets präsentieren, die mehr Speicher erfordern als lokal verfügbar ist, was somit zu einer wesentlichen Ressourcenleistungskraft führt.
Das bevorzugte Ausführungsbeispiel wirkt in einem elektronischen Netzwerk in Verbindung mit der Hostsoftware, die webbasierte Verwaltungsfähigkeiten für Peripheriegeräte liefert. Die Peripheriegeräte sind direkt an das Netzwerk über die neuen Schnittstellen angebracht (die „Schnittstelle"), die hierin ausgeführt sind. Die Hostsoftware kann eine beliebige allgemeine Software sein, die auf einem Inhaltsserver läuft (z. B. als CGI-Bin-Skripten und DLLs), und die eine Benutzerschnittstelle oberster Ebene für die Peripheriegeräteverwaltung bereitstellt. Eine solche Benutzerschnittstelle oberster Ebene sollte einen Benutzerzugriff auf eine Sammlung von spezifischen Seiten für eine Verwaltung der hierin beschriebenen neuen Schnittstelle und des zugeordneten Peripheriegeräts bereitstellen (z. B. Status, Konfiguration und Aufträge).
Das bevorzugte Ausführungsbeispiel schafft eine Web-Umleitungsfunktionalität, die eine webbasierte Peripheriegerät- Verwaltungslösung unterstützt, die auf JAVA-Applets basiert, und einen UI-Erzeuger oberster Ebene, der auf einem Inhaltsserver angeordnet ist. Es liegen HTTP-Hintergrundroutinen (d. h. Webserver) in dem Web-Umleitungsschema vor, die sowohl auf der Schnittstelle als auch einem Hostmaschinen-Inhaltsserver laufen. Webbrowserzugriffe auf die Schnittstellen-HTTP-Hintergrundroutine nach Peripheriegeräte- oder Schnittstellen-Inhalt werden durch die Schnittstellen-HTTP-Hintergrundroutine zu einem Inhaltsserver umgeleitet, wo die tatsächlichen HTML- oder JAVA-Applet-Dateien gespeichert sind. Die Schnittstelle erzeugt ferner HTML-Programmrohlingsdateien, um beim Umleiten von Zugriffen auf JAVA-Applets auf dem Inhaltsserver zu helfen.
1 ist ein schematisches Blockdiagramm, das die primären Systemkomponenten zeigt, die folgendes umfassen:

• Klientenbrowser 14;
• UI-Server oberster Ebene (TLUI; TLUI = Top level UI) 12;
• Peripheriegerät 18;
• Peripheriegeräteschnittstelle 16; und
• Inhaltsserver 10.

Die Operation der Erfindung wird nachfolgend in Verbindung mit 2–7 beschrieben.
2 ist ein schematisches Blockdiagramm, das eine Vorrichtungserkennung, UI-Erzeugung oberster Ebene und Klientenbrowserabruf einer UI-Seite oberster Ebene zeigt. Die Operation dieses Ausführungsbeispiels der Erfindung umfasst die nachfolgenden Aktionen, die in 2 durch Linien 21–24 identifiziert sind.
Schritt 1 – Entdeckung-Abfrage (21)
Der UI-Server oberster Ebene sendet Abfragen auf dem Netzwerk hinaus, um die verfügbaren Peripheriegeräteschnittstellen und Peripheriegeräte zu lokalisieren. Verschiedene Entdeckungs- und Verwaltungsprotokolle können verwendet werden, um verfügbare Vorrichtungen zu entdecken und Informationen über jede dieser Vorrichtungen wiederzugewinnen. Anfängliche Abfragen können rundgesendet oder über Gruppenruf an Gruppen von Vorrichtungen zu Entdeckungszwecken gesendet werden, gefolgt durch Abfragen, die sich auf jede Vorrichtung richten, um vorrichtungsspezifische Identifikationsinformation zu erhalten.
Schritt 2 – Entdeckung-Antwort (22)
Jede Vorrichtung antwortet mit den angeforderten Informationen auf die Abfrage oder die Abfragen des UI-Servers oberster Ebene.
Schritt 3 – TLUI-Erhalten (23)
Der Benutzer tritt in Wechselwirkung mit dem Klientenbrowser auf eine Weise, die verursacht, dass der Klientenbrow ser HTTP GET zu dem UI-Server oberster Ebene (TLUI-Server) für den URL der TLUI-Seite sendet (z. B. Eingeben eines URL, Auswählen eines Artikels aus einer Favoriten/Lesezeichen/Historie-Liste).
Schritt 4 – TLUI-Antwort (24)
Der UI-Server oberster Ebene empfängt das GET und ruft den UI-Erzeuger oberster Ebene 13 auf. Der UI-Erzeuger oberster Ebene erzeugt HTML für die TLUI-Seite (er kann dieses HTML dynamisch erzeugen). Auf der TLUI-Seite ist eine Peripheriegerätverwaltungs-Hypertextverknüpfung, der der Benutzer folgen kann, um ein peripheriegerätespezifisches Verwaltungs-JAVA-Applet aufzurufen. Der URL, das dieser Hyper textverknüpfung zugeordnet ist, ist der URL des Programmrohlingserzeugers 15 auf der Peripheriegeräteschnittstelle. Dieser URL umfasst Parameter, die zu dem Programmrohlingserzeuger weitergeleitet werden und die im Wesentlichen der Text für ein Applet-Etikett sind, das Bezug auf das Peripheriegeräteverwaltungs-JAVA-Applet nimmt. Der Klientenbrowser empfängt die TLUI-Seiten-HTML und präsentiert dem Benutzer die graphische TLUI-Seite.
Anmerkungen

• Die TLUI kann komplizierter sein als beschrieben ist und kann aus mehreren Seiten- und/oder Rahmen-Bereichen auf dem Bildschirm bestehen.
• Die TLUI kann aus JAVA-Applets und nicht HTML-Seiten aufgebaut sein.
• Verwaltung ist ein allgemeiner Ausdruck und könnte Konfiguration, Status, Steuerung oder andere Operationstypen mit der Peripherieschnittstelle oder dem Peripheriegerät umfassen.
• Die spezifische Peripheriegeräteverwaltung kann komplizierter sein als oben beschrieben ist und aus mehreren HTML-Seiten und/oder JAVA-Applets bestehen.

3 ist ein schematisches Blockdiagramm, das einen Benutzer zeigt, der eine Verknüpfung auf einer Seite folgt, wobei ein Klientenbrowser den Peripheriegeräteschnittstellen-Programmrohlingserzeuger aufruft und eine HTLM-Programmrohlingsdatei empfängt (z. B., um den Abruf von JAVA-Applet auszulösen). Die Operation dieses Ausführungsbeispiels der Erfindung umfasst die nachfolgenden Aktionen, die in 3 durch Linien 31, 32 identifiziert sind.
Schritt 1 – StubGen-Erhalten (Applet) (31)
Wenn der Benutzer der Peripheriegeräteverwaltungsverknüpfung auf der Seite folgt, führt der Klientenbrowser ein HTTP GET zu der Peripheriegeräteschnittstelle durch, um den URL für den Programmrohlingserzeuger (StubGen) zu erhalten, wodurch ebenfalls die URL-Parameter eingeleitet werden (z. B. der APPLET-Etikettentext).
Schritt 2 – StubGen-Antwort (Applet) (32)
Die Peripheriegeräteschnittstelle empfängt das GET und ruft den Programmrohlingserzeuger auf. Der Programmrohlingserzeuger erzeugt eine kleine HTML-Datei (genannt eine Programmrohlingsdatei), in der die eingeleiteten URL-Parameter zum Körper der HTML-Datei werden. In diesem Fall ist der URL-Parameter der Text für ein APPLET-Etikett, und die resultierende HTML-Programmrohlingsdatei enthält ein APPLET-Etikett, das Bezug auf das Peripheriegeräteverwaltungs-JAVA-Applet nimmt. Das APPLET-Etikett zeigt an, dass das JAVA-Applet auf der Peripheriegeräteschnittstelle angeordnet ist. Die HTML-Programmrohlingsdatei wird zu dem Klientenbrowser zurückgesendet.
Anmerkungen

Eine Zeichenfolge-Token-Ersetzung kann an den Inhalten der Programmrohlingsdatei durchgeführt werden, bevor dieselbe zu dem Browser zurückgesendet wird.

4 ist ein schematisches Blockdiagramm, das einen Klientenbrowser zeigt, der ein JAVA-Applet mit HTTP-Umleitung abruft. Die Operation dieses Ausführungsbeispiels der Erfindung umfasst die nachfolgenden Aktionen, die in 4 durch Linien 41–44 identifiziert sind.
Schritt 1 – Applet-Erhalten (41)
Der Klientenbrowser empfängt und verarbeitet die HTML-Programmrohlingsdatei. Beim Verarbeiten des APPLET-Etiketts sendet der Klientenbrowser ein HTTP GET zu der Peripheriegeräteschnittstelle, wodurch der URL für das JAVA-Applet spezifiziert wird. Der URL für das JAVA-Applet besteht aus einer speziellen Anfangsverzeichniswegkomponente (z. B. /redirect), gefolgt durch den relativen Weg zu dem JAVA-Applet.
Schritt 2 – Applet-Antwort (Umleitung) (42)
Die Peripheriegeräteschnittstelle erfasst/redirect und ruft die allgemeine Umleitung 17 auf. Die allgemeine Umleitung sendet eine Antwort zurück zu dem Klientenbrowser, die einen HTTP-Status von temporär bewegt anzeigt. Das Positionsfeld in der Antwort ist der URL des JAVA-Applets auf dem Inhaltsserver. Die allgemeine Umleitung entfernt die /redirect-Komponente aus dem URL und setzt an seine Stelle den Hostnamen und den anfänglichen Weg für die Position des JAVA-Applets auf dem Inhaltsserver. Die Antwort wird zu dem Klientenbrowser zurückgesendet.
Schritt 3 – Applet-Erhalten (43)
Der Klientenbrowser empfängt die Antwort und verarbeitet die Antwort mit dem Temporär-Bewegt-Status. Der Browser sendet ein HTML GET zu dem Inhaltsserver für den URL des JAVA-Applets (wie von der allgemeinen Peripheriegeräteschnittstellen-Umleitung empfangen wurde).
Schritt 4 – Applet-Antwort (44)
Der Inhaltsserver empfängt das GET, lokalisiert das spezifizierte JAVA-Applet und sendet das JAVA-Applet zu dem Klientenbrowser zurück. Der Klientenbrowser lädt das JAVA- Applet in die JAVA-Umgebung und das JAVA-Applet beginnt mit der Ausführung.
Anmerkungen

• Es sei angenommen, dass die Peripheriegeräteschnittstelle vorangehend mit dem URL-Weg zu den JAVA-Applets auf dem Inhaltsserver konfiguriert wurde.
• Eine Zeichenfolge-Token-Ersetzung kann an dem Umleitungs-URL in dem Positionsfeld der umgeleiteten Antwort durchgeführt werden.
• JAVA-Klassen-Datei-Bezugnahmen verwenden ebenfalls denselben Umleitungsmechanismus.

5 ist ein schematisches Blockdiagramm, das ein JAVA-Applet zeigt, das mit einer Peripheriegeräteschnittstelle und/oder Peripheriegeräten kommuniziert. Die Operation dieses Ausführungsbeispiels der Erfindung umfasst die nachfolgenden Aktionen, die in 5 durch Linien 51, 52 identifiziert sind.
Schritt 1 – Verw.-Anforderung (bzw. Mgmt-Anforderung) (51)
Das JAVA-Applet sendet eine Verwaltungsanforderung direkt zu der Peripherieschnittstelle und/oder dem Peripheriegerät unter Verwendung des oder der geeigneten Protokolle (z. B. SNMP).
Schritt 2 – Verw.-Antwort (52)
Die Peripherieschnittstelle und/oder das Peripheriegerät führt die angeforderten Verwaltungsaktionen durch und/oder sendet die angeforderten Verwaltungsinformationen zurück.
6 ist ein schematisches Blockdiagramm, das einen Klientenbrowser zeigt, der auf einen Peripherieschnittstel len-Haupt-URL bzw. -Wurzel-URL zugreift und zu einem UI-Erzeuger oberster Ebene umgeleitet wird. Die Operation dieses Ausführungsbeispiels der Erfindung umfasst die nachfolgenden Aktionen, die in 6 durch Zeilen 61–64 identifiziert sind.
Schritt 1 – Haupt-URL-Erhalten (61)
Der Benutzer tritt mit dem Klientenbrowser auf eine Weise in Wechselwirkung, die verursacht, dass der Klientenbrowser ein HTTP GET zu der Peripherieschnittstelle für den Haupt-URL (/) sendet.
Schritt 2 – Haupt-URL-Antwort (Umleitung) (62)
Die Peripherieschnittstelle empfängt das GET und ruft die Haupt-URL-Umleitung 19 auf. Die Peripherieschnittstellen-Haupt-URL-Umleitung sendet eine Antwort mit einem HTTP-Status von temporär bewegt, und der umgeleiteten URL-Position. In diesem Fall ist die umgeleitete URL-Position an der Peripherieschnittstelle als der URL des UI-Erzeugers oberster Ebene auf dem UI-Server oberster Ebene konfiguriert. Zusätzlich dazu kann der umgeleitete URL URL-Parameter umfassen, die Peripheriegeräteschnittstellen- und/oder Peripheriegeräte-spezifische Informationen enthalten.
Schritt 3 – Haupt-URL-Erhalten (63)
Der Klientenbrowser empfängt die Antwort und verarbeitet den Temporär-Bewegt-Status. Der Klientenbrowser sendet ein HTML GET zu dem UI-Server oberster Ebene für den URL des UI-Erzeugers oberster Ebene (wie von der Peripherieschnittstellen-Haupt-URL-Umleitung empfangen wurde, die URL-Parameter umfasst).
Schritt 4 – Haupt-URL-Antwort (64)
Der UI-Erzeuger oberster Ebene erzeugt eine TLUI-Seite, die zu dem Klientenbrowser zurückgesendet werden soll. Der UI-Erzeuger oberster Ebene (TLUI-Erzeuger; TLUI = top level UI) kann URL-Parameter verwenden (die Peripherieschnittstellen- und/oder Peripheriegeräte-spezifische Informationen enthalten), um den Peripherieschnittstellen- und Peripheriegeräte-spezifischen Seiteninhalt auszuwählen. Die TLUI-Seite wird zu dem Klientenbrowser zurückgesendet. Der Klientenbrowser empfängt die TLUI-Seiten-HTML und präsentiert die graphische TLUI-Seite dem Benutzer.
Anmerkungen

• Es sei angenommen, dass der Haupt-Umleitungs-URL in der Peripherieschnittstelle konfiguriert wurde.
• Zeichenfolgen-Token-Ersetzung kann an dem Haupt-Umleitungs-URL durchgeführt werden.

7 ist ein schematisches Blockdiagramm, das einen Browser zeigt, der auf einen Peripherieschnittstellen-Haupt-URL zugreift und zu einer HTML-Homepage umgeleitet wird. Die Operation dieses Ausführungsbeispiels der Erfindung umfasst die nachfolgenden Aktionen, die in 7 durch Zeilen 71–74 identifiziert sind.
Schritt 1 – Haupt-URL-Erhalten (71)
Der Benutzer tritt mit dem Klientenbrowser auf eine Weise in Wechselwirkung, die verursacht, dass der Klientenbrowser ein HTTP GET zu der Peripherieschnittstelle für den Haupt-URL (/) sendet.
Schritt 2 – Haupt-URL-Antwort (Umleitung) (72)
Die Peripherieschnittstelle empfängt das GET und ruft die Haupt-URL-Umleitung auf. Die Peripherieschnittstellen-Haupt-URL-Umleitung sendet eine Antwort mit einem HTTP-Status von temporär bewegt, und der umgeleiteten URL-Position. In diesem Fall ist die umgeleitete URL-Position auf der Peripherieschnittstelle als der URL einer freistehenden HTML-Homepage auf dem Inhaltsserver konfiguriert.
Schritt 3 – Haupt-URL-Erhalten (73)
Der Klientenbrowser empfängt die Antwort und verarbeitet den Temporär-Bewegt-Status. Der Klientenbrowser sendet ein HTML GET zu dem Inhaltsserver für den URL der alleinstehenden HTML-Homepage (wie empfangen von der Peripherieschnittstellen-Haupt-URL-Umleitung).
Schritt 4 – Haupt-URL-Antwort (74)
Der Inhaltsserver empfängt das GET, lokalisiert die spezifizierte HTML-Seite und sendet die HTML-Seite zu dem Klientenbrowser zurück. Der Klientenbrowser zeigt die Seite dem Benutzer an. An der alleinstehenden Homepage besteht eine Hypertextverknüpfung, der der Benutzer folgen kann, um das peripheriespezifische Verwaltungs-JAVA-Applet aufzurufen. Der URL, der diesem Artikel zugeordnet ist, ist der URL des Programmrohlingserzeugers auf der Peripherieschnittstelle. Der URL umfasst Parameter, die zu dem Programmrohlingserzeuger weitergeleitet werden und die im Wesentlichen der Text für ein APPLET-Etikett sind, das Bezug auf das Peripherieverwaltungs-JAVA-Applet nimmt.
Anmerkungen

• Es sei angenommen, dass der Haupt-Umleitungs-URL in die Peripherieschnittstelle konfiguriert wurde.
• Die alleinstehende HTML-Homepage kann komplizierter sein als beschrieben wurde und aus mehreren Seiten- und/oder Rahmen-Bereichen auf dem Bildschirm bestehen.
• Ein Zeichenfolgen-Token-Ersatz kann an dem Haupt-Umleitungs-URL durchgeführt werden.

Web-Umleitung
Die Grundlagen des Web-Umleitungsschemas sind wie folgt:

• Ein UI-Erzeuger oberster Ebene läuft als CGI-Bin-Skripten und DLLs auf dem UI-Server oberster Ebene mit den zugeordneten URLs. Der UI-Erzeuger oberster Ebene schafft eine Benutzerschnittstelle hoher Ebene für eine Peripherieverwaltung, einschließlich z. B. Entdeckungs- und Suchfähigkeiten, Gruppenverwaltung und Navigation. Der UI-Erzeuger oberster Ebene führt die HTML-Seiten zu dem Browser zu, um die UI oberster Ebene zu präsentieren. Diese UI-HTML-Seiten oberster Ebene umfassen Hypertextverknüpfungen zu URLs für Schnittstellen- und Peripheriegerät-spezifische Seiten. Wenn der Benutzer durch die UI-Seiten oberster Ebene navigiert, wählen sie Schnittstellen- und Peripheriegerät-spezifische Seiten aus (z. B. Druckerstatus und Schnittstellenkonfiguration), wodurch verursacht wird, dass der Browser Verknüpfungen zu diesen Seiten folgt, durch Durchführen von HTTP GETs der URLs für die Schnittstellen- und Peripheriegerät-spezifischen Seiten.
• Die Schnittstellen- und Peripheriegerät-spezifischen Seiten sind als JAVA-Applets und -Klassen implementiert. Sie könnten nach Wunsch ebenfalls HTML oder andere Dateien sein. Diese JAVA-Applet- und -Klassen-Dateien sind auf dem Inhaltsserver gespeichert, laden/laufen in dem Browser und verwenden dann SNMP, um weiter mit der Schnittstelle oder dem Peripheriegerät zu kommunizieren.
• Das Laden/Ausführen eines JAVA-Applets folgt der Browser einer Hypertextverknüpfung von der UI-Seite oberster Ebene zu einer kleinen HTML-Seite, die ein HTML-APPLET-Etikett enthält, das den URL der JAVA-Applet-Datei auf dem Inhaltsserver anzeigt. Das APPLET-Etikett hat verschiedene Parameter, die den Namen der JAVA-Applet-Datei (CODE=), den absoluten URL zu dem JAVA-Applet-Dateiverzeichnis (CODEBASE=) und die Höhe und Breite des Bildschirmbereichs, der durch das Applet eingenommen wird (HEIGHT=, WIDTH=), anzeigt. Ein HTML-Programmrohlingsdateimechanismus wird verwendet, um den JAVA-Applet-Dateiabruf auszulösen, der sowohl die Schnittstelle als auch den IU-Erzeuger oberster Ebene umfasst:
– Die Schnittstelle enthält eine eingebettete HTTP-Hintergrundroutine (d. h. Webserver), die dynamisch die HTML-Programmrohlingsseiten erzeugt, die die APPLET-Etiketten enthalten. Ein spezifischer URL („/stubgen") auf der Schnittstelle ruft den HTML-Programmrohlingsseitenerzeuger auf. Der Schnittstellen-HTML-Programmrohlingsseitenerzeuger ist insofern generisch, indem er einen Parameter („body=") nachfolgend zu dem Anforderungs-URL nimmt und dessen Wert als den Körper der HTML-Seite nimmt, die zu dem Browser zurückgesendet wird. Die Schnittstelle führt einen Token-Ersatz an dem Körper der HTML-Programmrohlingsseite durch, wodurch ein Einschluss von Konfigurations-/Identitäts-Informationen ermöglicht wird, die auf der Schnittstelle enthalten sind. Die Ersatz-Token umfassen: Den voll qualifizierten Bereichsnamen und Basis-URL-Weg der Position der Hostsoftware auf dem Inhaltsserver; Den voll qualifizierten Schnittstellenbereichsnamen; Die Schnittstellen-MAC-Adresse; Die Schnittstellenmodell-Identifiziererzeichenfolge; und Die Peripheriemodell-Identifiziererzeichenfolge.
– Der UI-Erzeuger oberster Ebene enthält Informationen, die sich auf die Position der JAVA-Applet-Dateien auf dem Inhaltsserver, die Höhe/Breite des Applet-Bereichs und ob der Applet-Dateiname kundenspezifisch sein sollte, um Zeichenfolgen für den Schnittstellentyp des Peripheriegerätetyps zu enthalten, beziehen. Um ein JAVA-Applet aus einer UI-Seite oberster Ebene aufzurufen, platziert der UI-Erzeuger oberster Ebene eine Hypertextverknüpfung in der Seite, die den URL des Schnittstellen-HTML-Programmrohlingserzeugers enthält. Der URL enthält ferner einen Parameter „body=", der tatsächlich der gesamte APPLET-Etikettentext ist, der in die HTML-Programmrohlingsseite eingefügt werden soll, die durch die Schnittstelle zurückgesendet wird. Zusätzlich dazu umfasst der APPLET-Etikettentext jegliche Token, von denen der UI-Erzeuger oberster Ebene erfordert, dass die Schnittstelle dieselben in die HTML-Programmrohlingsseite ersetzt, wodurch eine Modifikation des JAVA-Applet-Dateinamens oder des -Verzeichniswegs verursacht wird. Wenn der Benutzer der Hypertextverknüpfung zu der Schnittstellen- und Peripheriegerät spezifischen Seite folgt, sendet der Browser eine HTTP-GET-Anforderung zu der Schnittstelle, die den URL des Programmrohlingsdateierzeugers spezifiziert und den „body="-Parameter in dem Anforderungs-URL weiterleitet. Die Schnittstelle sendet zu dem Browser eine kleine HTML-Seite zurück, die den „body="-Wert mit dem ersetzten Token enthält.
• Sobald der Browser die HTML-Programmrohlingsseite empfängt und das APPLET-Etikett verarbeitet, fährt er dann fort zum Durchführen eines HTTP GET der JAVA-Applet-Datei. Um innerhalb der JAVA-Sicherheitseinschränkungen zu arbeiten, muss der Browser die HTTP-GET-Anforderungen nach JAVA-Applet-/Klassen-Datei-URLs zu der Schnittstelle durchführen und diese Anforderungen zu den URLs auf dem Inhaltsserver umleiten lassen. Ein HTTP-Umleitungsmechanismus wird verwendet, der sowohl den UI-Erzeuger als auch die Schnittstelle oberster Ebene umfasst. In dem APPLET-Etikettentext (den die UI-Hypertextverknüpfung zu dem Schnittstellen-HTML-Programmrohlingserzeuger als den Parameter body= weiterleitet) ist der Weg zu der JAVA-Applet-Datei (in dem Parameter CODEBA-SE=) und der Name der JAVA-Applet-Datei (in dem Parameter CODE=). Der Weg, der in dem Parameter CODEBASE= spezifiziert ist, enthält eine anfängliche Komponente „/redirect", die ungeändert in der HTML-Programmrohlingsdatei zurückgesendet wird und die zu dem Weg wird, der durch den Browser verwendet wird, wenn derselbe ein HTTP GET der JAVA-Applet-Datei durchführt.
• Die eingebettete HTTP-Hintergrundroutine (d. h. Webserver) an der Schnittstelle führt die Umleitung einer HTTP-Anforderung durch, die einen spezifischen Anfangsverzeichnisweg („/redirect") in dem Anforderungs-URL enthält. Für HTTP-Anforderungen, deren URL den Umleitungsverzeichnisweg enthält, sendet die Schnitt stelle eine HTTP-Antwort zurück, die einen Statuscode „temporär bewegt" und einen Positions-URL enthält, der der Anforderungs-URL mit abgestreiftem Weg/redirect und einem vorkonfigurierten Hoststoftwarebasis-URL ist, der an seiner Stelle eingefügt ist. Die Schnittstelle führt ferner einen Token-Ersatz an dem Antwortpositions-URL durch, wenn Token vorhanden sind.
• Sobald der Browser das JAVA-Applet wiedergewinnt und das Abspielen desselben startet, führt das JAVA-Applet eine SNMP-Anforderung zu der Schnittstelle oder dem Peripheriegerät durch, um spezifische Operationen auszuführen.
• Die Schnittstelle führt eine Umleitung aller HTTP-Anforderungen für seinen Haupt- („/") oder Homepage-URL durch, ähnlich zu dem allgemeinen Umleitungsmechanismus. Ein spezifischer Homepage-URL ist in der Schnittstelle konfiguriert. Wenn die Schnittstelle eine HTTP-Anforderung für ihre Homepage empfängt, sendet sie eine HTTP-Antwort mit einem Statuscode „temporär bewegten" zurück und einen Positions-URL, der vorkonfiguriert wurde, der aber einem Token-Ersatz unterzogen wird.

Webumleitungsfunktionen
Der Webumleitungsmechanismus ist aus den nachfolgenden Fähigkeiten aufgebaut, die in Firmware eingebettet sind:

• Konfigurationsinformationen;
• Zeichenfolgenverarbeitung;
• HTTP-Haupt-URL-Umleitung;
• HTML-Programmrohlingsdateierzeugung;
• allgemeine HTTP-URL-Umleitung; und
• lokaler Hauptseiteninhalt.

Konfigurationsinformationen
Verschiedene Stücke von Konfigurationsinformationen werden auf der Schnittstelle als Unterstützung der Webumleitungsfunktionalität beibehalten. Der Wert jedes Konfigurationsartikels kann wiedergewonnen und über SNMP eingestellt werden. Tabelle 1 (unten) listet diese Konfigurationsinformationen auf.
Tabelle 1 – Konfigurationsinformationen
Zeichenfolgenverarbeitung
Eine Zeichenfolgenverarbeitung wird an verschiedenen Zeichenfolgen durchgeführt, die die Schnittstelle zu dem Browser weiterleitet. Die spezifischen Zeichenfolgenverarbeitungsoperationen sind nachfolgend beschrieben.

• Leerstellenersatz: Alle „+"-Zeichen, die in der Zeichenfolge angetroffen werden, werden in ASCII-Leerstellen umgewandelt.
• Escape-Umwandlung: Alle Escape-codierten Zeichen, die in der Zeichenfolge angetroffen werden, werden in ihre Einzelzeichenentsprechung umgewandelt. Allgemeine Zeichen in den URL-Parametern, die zu der Schnittstelle weitergeleitet werden, die eine Escape-Codierung erfordern, sind in Tabelle 2 unten erläutert.

Tabelle 2 – Allgemeine Zeichen, die eine Escape-Codierung erfordern
Token-Ersatz
Wenn bestimmte Token in einer Zeichenfolge angetroffen werden, ersetzt die Schnittstelle den geeigneten Wert. Tabelle 3 unten definiert die Token-Namen/-Syntax und die Werte, die eingesetzt werden. Token-Namen sind fallunempfindlich und sind eingeschlossen durch Klammer auf und Klammer zu „(„ und ")" als Teil der Token-Namen-Syntax.
Tabelle 3 – Token-Ersatz
HTTP-Haupt-URL-Umleitung
Die HTTP-Hauptseitenumleitungsfunktion führt eine Umleitung von http-GET- oder HEAD-Anforderungen nach dem Haupt-URL („/") durch. Wenn die Schnittstelle eine HTTP-Anforderung nach dem Haupt-URL („/") empfängt, sendet sie eine HTTP-Antwort mit einem Statuscode „temporär bewegt" und einem Positionsfeld zurück, das den aktuellen URL zum Zugreifen anzeigt. Der Positionsfeldwert wird erzeugt durch Nehmen des xRootRedirectURL-Konfigurationsartikelwerts und Durchführen eines Token-Ersatzes an diesem Wert. Wenn der xRootRedirectURL-Artikel nicht konfiguriert wurde, kehrt die Schnittstelle zu ihrem allein operierenden Verhalten zurück.
HTML-Programmrohlingsdateierzeugung
Die HTML-Programmrohlingsdateierzeugung ermöglicht eine dynamische Erzeugung von kleinen HTML-Dateien mit dem Inhalt der HTML-Datei, die als ein Parameter an dem Anforderungs-URL eingeleitet wird. Dieser Mechanismus kann verwendet werden, um kleine HTML-Dateien zu erzeugen, die ein APPLET-Etikett enthalten, zum Aufrufen eines JAVA-Applets, und die einen Abschnitt des HTML-Dateikörpers mit Informationen kundenspezifisch eingerichtet haben, die spezifisch für eine bestimmte Schnittstelle sind.
Die HTML-Programmrohlingsdateierzeugung tritt auf, wenn eine HTTP-GET- oder -HEAD-Anforderung für den „/stubgen"-URL (stubgen = Programmrohlingserzeugung) empfangen wird. Der Wert des Parameters ?body= am Ende des Anforderungs-URL wird als der Körper der zurückgesendeten HTML-Programmrohlingsdatei verwendet. Eine Zeichenfolgenverarbeitung wird an dem Körper der HTML-Programmrohlingsdatei durchgeführt, bevor er zu dem Anforderer zurückgesendet wird.
Wenn der nachfolgende Anforderungs-URL spezifiziert ist:
http:/jetdirect1.rose.hp.com/stubgen?body=this+is+the+body+of+the+HTML+stub+file, (=dies+ist+der+Körper+von+der+HTML+Programmrohlings+Datei)
Dann ist der zurückgesendete HTTP-Anfangsblock:
HTTP/1.0 200 OK
Und der zurückgesendete HTML-Inhalt ist:
<HTML>
<HEAD>
<TITLE> stub file </TITLE>
<HEAD>
<BODY>
this is the body of the HTML stub file
</BODY>
</HTML>
Allgemeine HTTP-URL-Umleitung
Die allgemeine HTTP-Umleitungsfunktion führt eine Umleitung von HTTP-GET-, -HEAD- und -POST-Anforderungen für alle URLs mit einer bestimmten Anfangswegkomponente durch. Wenn die Schnittstelle eine HTTP-Anforderung für einen URL empfängt, der eine Anfangswegkomponente von „/redirect" aufweist, sendet sie eine HTTP-Antwort mit einem Statuscode „temporär bewegt" und einem Positionsfeld zurück, das den tatsächlichen URL zum Zugreifen anzeigt. Der Positionsfeldwert wird erzeugt, durch Nehmen des Anforderungs-URL, Ersetzen der „/redirect"-Komponente mit dem Wert des xGeneralRedirect-URL-Konfigurationsartikels und Durchführen eines Token-Ersatzes an dem resultierenden URL.
Wenn der xGeneralRedirectURL-Artikel nicht konfiguriert wurde, sendet die Schnittstelle eine HTTP-Antwort mit einem Statuscode zurück.
Hostsoftwareverwendung
Es besteht eine Anzahl von Möglichkeiten, wie die Hostsoftware die Webumleitungsfunktionalität verwenden kann.
Beispiel 1
Dieses Beispiel zeigt die allgemeine HTML-Programmrohlingsdatei und die HTTP-Umleitungsverwendung. Die Beispielkonfiguration ist, wie in Tabelle 4 und 5 unten gezeigt ist.
Tabelle 4 – Beispiel 1: Webserver-Einstellung
Tabelle 5 – Beispiel 1: Schnittstellenkonfiguration
Ein Beispieldateiensatz und eine Aktionssequenz ist wie folgt:
Der UI-Erzeuger oberster Ebene führt eine HTML-Seite zu dem Browser zu. Diese Seite enthält einen gewünschten Druckerstatus-Hyperlink, wie folgt:
<A HREF="http://printer1.rose.hp.com/stubgen?body=<APPLET+CODE="Printerstatus.class"+ CODEBASE="http://(InterfaceName)/redirect/java/"+HEIGHT=500+WIDTH=500>+<PARAM+NAME=LANG+VALUE=EN>+</APPLET>">Printer Status</A>
Da jedoch einige der Zeichen in dem URL-Parameter codiert werden müssen, ist die tatsächliche Druckerstatus-Hypertextverknüpfung wie folgt:
<A HREF="http://printer1.rose.hp.com/stubgen?body=%22%3cAPPLET+CODE=%22Printerstatus.class%22+CODEBASE=%22http://(InterfaceName)/redirect/java/%22+HEIGHT=500+WIDTH=500%3e+%3cPARAM+NAME=LANG+VALUE=EN%3e+%3c/APPLET%3e%22>Printer Status</A>
Wenn der Benutzer der Druckerstatus-Hypertextverknüpfung folgt, sendet der Browser eine HTTP-GET-Anforderung zu der Schnittstelle (printer1.rose.hp.com) mit dem nachfolgenden (es wird darauf hingewiesen, dass das/java/-Verzeichnis immer in einer festen Position relativ zu dem Schnittstellen-xGeneralRedirectURL-Weg ist):
<GET/stubgen?body=%22%3cAPPLET+CODE=%22Printerstatus.class%22+CODEBASE=%22http://(InterfaceName)/redirect/java/%22+HEIGHT=500+WIDTH=500%3e+%3cPARAM+NAME=LANG+VALUE=EN%3e+%3c/APPLET%3e%22 HTTP1.0
Die Schnittstelle verarbeitet die HTTP-Anforderung nach einer Programmrohlingserzeugung und sendet die nachfolgende HTML-Seite als eine Antwort zurück (Ersatz wurde an dem Token „(InterfaceName)" durchgeführt):
<HTML>
<HEAD>
<TITLE> stub file </TITLE>
<HEAD>
<BODY>
<APPLET CODE _ „Printerstatus.class"CODEBASE="http://printer1.rose.hp.com/redirect/java"WIDTH=500 HEIGHT= 500><PARAM NAME=LANG VALUE=EN></APPLET>
</BODY>
</HTML>
Der Browser verarbeitet die HTML-Programmrohlingsseite und sendet eine HTTP-GET-Anforderung zu der Schnittstelle (printer1.rose.hp.com) wie folgt:
GET/redirect/java/Printerstatus.class HTTP1.0
Die Schnittstelle verarbeitet die HTTP-Anforderung für eine Umleitung und sendet eine HTTP-Antwort mit den nachfolgenden Informationen zurück (der Weg/redirect wurde abgestreift und der Serverbasis-URL wurde eingefügt):
HTTP/1.0 302 Moved Temporarily (= temporär bewegt)
Position: http://server.rose.hp.com/Webjetadmin/java/Printerstatus.class
Der Browser verarbeitet die HTTP-Antwort und sendet die HTTP-GET-Anforderung zu dem Inhaltsserver wie folgt:
GET/Webjetadmin/java/Printerstatus.class HTTP1.0
Der Inhaltsserver verarbeitet die HTTP-Anforderung und sendet die Inhalte der JAVA-Applet-Datei zurück.
[JAVA-Applet-Inhalte]
Ein Browser, der auf die Schnittstellen-Wurzel oder -Homepage zugreift, sendet direkt eine HTTP-Anforderung zu der Schnittstelle wie folgt:
GET/HTTP1.0
Die Schnittstelle sendet eine HTTP-Antwort mit den nachfolgenden Feldern (Ersatz wurde durchgeführt an dem Token „(InterfaceMAC)" bei der vorkonfigurierten Schnittstellen-Homepage-URL-Umleitung):
HTTP/1.01 302 Moved Temporarily
Position: http://server.rose.hp.com/Webjetadmin/Webjetadmin.exe?addr=080009123456
Der Browser verarbeitet die Antwort und sendet eine HTTP-Anforderung zu dem Inhaltsserver wie folgt:
GET/Webjetadmin/Webjetadmin.exe?addr=080009123456HTTP1.0
Der Inhaltsserver verarbeitet die HTTP-Anforderung, ruft den UI-Erzeuger oberster Ebene auf und sendet eine HTML-Seite für die UI oberster Ebene zurück:
[HTML-Seiteninhalt für UI oberster Ebene]
Allein operierendes Haupt-URL-Verhalten
Wenn die Schnittstelle noch nicht mit einem xRootRedirectURL-Wert konfiguriert wurde, funktioniert sie im allein operierenden Modus, da sie einen Inhaltsserver nicht identifizieren kann, um Anforderungen nach seiner Wurzelseite zu handhaben.
Allein operierende Optionen umfassen:

• Nicht auf HTTP-Anforderungen antworten.
• Antworten mit einer HTML-Seite, die Text enthält, der die Position der WebJetAdmin-Software anzeigt.
• Antworten mit einer HTML-Seite, die einen einfachen Peripheriegerät/Schnittstellen-Status mit Identifizierungsinformationen und Text enthält, der die Position der WebJetAdmin-Software anzeigt.
• Liefern von Konfigurationsseiten, die Telnet-Konfigurationsfähigkeiten entsprechen.

HTTP-Umleitung
Das HTTP-Protokoll unterstützt die Umleitung von browsererzeugten HTTP-Anforderungen von einer HTTP-Hintergrundroutine zu einer anderen. Dies wird wie folgt erreicht:

• Der Browser sendet eine HTTP-Anforderung zu einer HTTP-Hintergrundroutine, die den Anforderungs-URL spezifiziert.
• Die HTTP-Hintergrundroutine sendet eine HTTP-Antwort zurück zu dem Browser mit einem Statuscode „permanent bewegt" oder „temporär bewegt" und mit dem neuen URL gegeben durch das Positionsfeld in der Antwort. Die HTTP-Hintergrundroutine weist eine beträchtliche Breite dahingehend auf, was der neue URL ist, und kann dynamisch den neuen URL, falls erwünscht, erzeugen. Der neue URL kann eine HTTP-Hintergrundroutine auf einer anderen Maschine (z. B. einem Inhaltsserver) anzeigen.
• Der Browser empfängt die HTTP-Antwort und sendet dann eine HTTP-Anforderung zu dem neuen URL, wo der tatsächliche Inhalt gespeichert ist.
• Die HTTP-Hintergrundroutine verarbeitet die HTTP-Anforderung und sendet eine Antwort zu dem Browser mit dem tatsächlichen Inhalt zurück.

JAVA-Applet-Aufruf
Ein JAVA-Applet liegt in einer Datei vor, die von einer HTTP-Hintergrundroutine (d. h. Webserver) in einen Browser geladen wird oder innerhalb der JAVA-Ausführungsumgebung auf diesem Browser ausgeführt wird. Ein JAVA-Applet muss über ein APPLET-Etikett von innerhalb einer HTML-Datei aufgerufen werden. Das HTML-APPLET-Etikett hat die nachfol gende Syntax (es können andere Parameter zwischen dem Applet-Startetikett und dem -Endetikett vorliegen):
<APPLET CODE=xxx CODEBASE=xxx HEIGHT=xxx WIDTH=xxx></APPLET>
Die APPLET-Etikettparameter sind wie folgt:

• CODE – spezifiziert den Namen der Datei, die das JAVA-Applet enthält, relativ zu dem CODEBASE-URL (z. B. Printerstatus.class);
• CODEBASE – spezifiziert den Basis-URL von dort, wo das JAVA-Applet angeordnet ist, einschließlich dem Bereichsnamen und dem Verzeichnisweg (z. B. http://server.rose.hp.com/Webjetadmin/java/);
• HEIGHT – reservierte Seitenbereichshöhe in Pixeln; und
• WIDTH – reservierte Seitenbereichsbreite in Pixeln.

Das Laden und Betreiben eines JAVA-Applet in einem Browser umfasst die nachfolgenden Schritte:

• Der Benutzer klickt auf einen Bildschirmbereich, wodurch verursacht wird, dass der Browser einer Hyperlink folgt. Der Hyperlink-URL ist der URL für die HTML-Programmrohlingsdatei.
• Der Browser führt ein HTTP GET eines HTML-Programmrohlingsdatei-URL durch.
• Die HTTP-Hintergrundroutine sendet die Inhalte der angeforderten HTML-Programmrohlingsdatei zurück. Die HTML-Programmrohlingsdatei enthält das APPLET-Etikett, das den URL der JAVA-Applet-Datei anzeigt. Der Browser liest und verarbeitet die HTML-Programmrohlingsdateiinhalte und trifft auf das APPLET-Etikett.
• Der Browser führt ein HTTP GET des JAVA-Applet-Datei-URL durch. Normalerweise verbindet der Browser die HTTP-Hintergrundroutine, von der er die HTML-Programmrohlingsdatei empfangen hat, wieder, um ferner die JAVA-Applet-Datei zu erhalten. Wenn jedoch der CODEBASE-Parameter in der HTML-Programmrohlingsdatei spezifiziert ist, dann verbindet sich der Browser mit dem HTTP-Hintergrundroutinen-URL, der in dem CODEBASE-Etikett spezifiziert ist, um die JAVA-Applet-Datei zu erhalten.
• Die HTTP-Hintergrundroutine sendet die Inhalte der angeforderten JAVA-Applet-Datei zurück. Der Browser liest die JAVA-Applet-Dateiinhalte, lädt sie in den Speicher und betreibt sie innerhalb der JAVA-Ausführungsumgebung.
• Das JAVA-Applet kann dann SNMP/PML und/oder HTTP-Zugriffe durchführen, um benötigte Informationen für die Benutzerschnittstellenpräsentation zu sammeln.

JAVA-Sicherheit und -Umleitungen
Das gegenwärtige JAVA-Sicherheitsmodell erlegt die Einschränkung auf, dass ein ausführendes JAVA-Applet nur eine Netzwerkkommunikation mit dem Host durchführen kann, von dem das JAVA-Applet ursprünglich geladen wurde. Somit kann ein JAVA-Applet nur SNMP-Pakete zu einer Schnittstelle senden, wenn der Browser das JAVA-Applet von dieser Schnittstelle über ein HTTP GET geladen hat.
Unter Verwendung des HTTP-Umleitungsmechanismus ist es jedoch möglich, dass das JAVA-Applet auf einem Inhaltsserver gespeichert wird und nicht auf der Schnittstelle oder dem Peripheriegerät und trotzdem innerhalb der JAVA-Sicherheitseinschränkungen funktioniert. Um dies durchzuführen, muss die Schnittstelle auf das HTTP GET des JAVA-Applets antworten, mit dem HTTP-Temporär-Bewegt-Statuscode, und die tatsächliche Position (URL) des JAVA-Applets in dem Positionsfeld der HTTP-Antwort spezifizieren.
Zusätzlich dazu kann ein ausführendes JAVA-Applet Bezug auf eine Anzahl von Klassendateien nehmen und dieselben abrufen. Diese Klassendateien sind relativ zu und zusammen mit dem angeordnet, von wo das JAVA-Applet abgerufen wurde.

Claims

Ein Umleitungssystem zum Bereitstellen eines vergrößerten Inhalts für eine oder mehrere ressourceneingeschränkte Vorrichtungen in einem elektronischen Netzwerk, wobei das System folgende Merkmale aufweist: einen Browser (14), der einer Benutzerposition zugeordnet ist; einen Inhaltsserver (10); eine Peripherieschnittstelle (16), die eine eingebettete Hintergrundroutine aufweist, die wirksam ist, um dynamisch Programmrohlingsseiten zu erzeugen, die Applet-Etiketten enthalten, wobei eine spezifische Adresse an der Peripherieschnittstelle (16) angeordnet ist, um einen Programmrohlingsseitenerzeuger aufzurufen, der einen Parameter nachfolgend zu einer Anforderungsadresse nimmt und den Parameterwert als den Körper einer Programmrohlingsseite verwendet, die zu dem Browser zurückgeleitet wird; und einen Benutzerschnittstellenerzeuger (13), der einem Benutzerschnittstellenserver (12) zugeordnet ist, wobei der Benutzerschnittstellenerzeuger (13) angeordnet ist, um eine systemweite Adressierung und eine Benutzerschnittstelle für eine Verwaltung der ressourceneingeschränkten Vorrichtung zu liefern, wobei der Benutzerschnittstellenerzeuger (13) ferner angeordnet ist, um Informationsseiten zu dem Browser zu liefern, wobei die Informationsseiten Verknüpfungen zu Adressen für Schnittstellenseiten und peripheriespezifische Seiten umfassen, wobei die Schnittstellenseiten und die peripheriespezifischen Seiten auf dem Inhaltsser ver (10) gespeichert sind, und wobei eine Benutzernavigation durch Informationsseiten Schnittstellenseiten und peripheriespezifische Seiten auswählt, wobei der Browser (14) wirksam ist, um den Verknüpfungen zu diesen Schnittstellenseiten und peripheriespezifischen Seiten zu folgen.
Das System gemäß Anspruch 1, bei dem der Browser (14) angeordnet ist, um den Verknüpfungen zu den Schnittstellenseiten und den peripheriespezifischen Seiten zu folgen, durch Erhalten von Adressen für Schnittstellenseiten und peripheriespezifische Seiten.
Das System gemäß Anspruch 1 oder 2, bei dem die Schnittstellenseiten und die peripheriespezifischen Seiten als Applet- und Klassen-Dateien implementiert sind, wobei die Applet- und Klassen-Dateien angeordnet sind, um in dem Browser (14) zu laden und ausgeführt zu werden, wobei die Applet- und Klassen-Dateien angeordnet sind, um mit der Peripherieschnittstelle (16) und dadurch der Vorrichtung zu kommunizieren.
Das System gemäß Anspruch 1, 2 oder 3, bei dem der Browser die Peripherieschnittstelle (16) kontaktiert, wobei die Peripherieschnittstelle (16) angeordnet ist, um den Browser (14) unter Verwendung einer Informationsseitenumleitung umzuleiten.
Das System gemäß Anspruch 4, bei dem der Browser (14) angeordnet ist, um den Benutzerschnittstellenserver an einer umgeleiteten Position zu kontaktieren, die die Verknüpfung enthält, wobei die Verknüpfung angeordnet ist, um den Benutzerschnittstellenserver (12) anzuweisen, die Peripherieschnittstelle (16) von einer Umleitungsadresse zu kontaktieren und Daten, die an der Adresse enthalten sind, zu der Peripherieschnittstelle (16) weiterzuleiten, wodurch verursacht wird, dass eine Seite zu dem Browser (14) von der Peripherie schnittstelle (16) gesendet wird, wobei die Seite eine Bezugnahme auf eine Applet-Datei enthält.
Das System gemäß Anspruch 5, bei dem die Bezugnahme auf die Applet-Datei einen Kontakt zu der Peripherieschnittstelle (16) an der Umleitungsadresse einrichtet, wodurch die Applet-Datei heruntergeladen wird, um die Funktionalität der Peripherieschnittstelle (16) zu verbessern.
Das System gemäß Anspruch 6, bei dem der Browser (14) angeordnet ist, um die Applet-Datei von einer Umleitungsposition auf den Inhaltsserver (10) herunterzuladen.
Das System gemäß Anspruch 7, bei dem der Browser (14) angeordnet ist, um mit der Peripherieschnittstelle (16) zu kommunizieren, um erforderliche Informationen wiederzugewinnen, sobald die Applet-Datei durch den Browser (14) geladen wurde.
Das System gemäß Anspruch 1, bei dem der Benutzerschnittstellenerzeuger (13) ferner folgendes Merkmal aufweist: einen Programmrohlingsdateimechanismus zum Auslösen eines Applet-Dateiabrufs.
Ein Umleitungsverfahren zum Liefern von vergrößertem Inhalt für eine oder mehrere ressourceneingeschränkte Vorrichtungen auf einem elektronischen Netzwerk, wobei das Verfahren folgende Schritte aufweist: Verwenden eines Browsers (14), der einer Benutzerposition zugeordnet ist; Verwenden eines Inhaltsservers (10); Verwenden einer Peripherieschnittstelle (16), die eine eingebettete Hintergrundroutine aufweist, die wirksam ist, um dynamisch Programmrohlingsseiten zu erzeugen, die Applet-Etiketten enthalten, wobei eine spezifische Adresse an der Peripherieschnittstelle (16) angeordnet ist, um einen Programmrohlingsseitenerzeuger aufzurufen, der einen Parameter nachfolgend zu einer Anforderungsadresse nimmt und den Parameterwert als den Körper einer Programmrohlingsseite verwendet, die zu dem Browser zurückgeleitet wird; und eines Benutzerschnittstellenerzeugers (13), der einem Benutzerschnittstellenserver (12) zugeordnet ist, wobei der Benutzerschnittstellenerzeuger (13) angeordnet ist, um eine systemweite Adressierung und eine Benutzerschnittstelle für eine Verwaltung der ressourceneingeschränkten Vorrichtung zu liefern, wobei der Benutzerschnittstellenerzeuger (13) ferner angeordnet ist, um Informationsseiten zu dem Browser zu liefern, wobei die Informationsseiten Verknüpfungen zu Adressen für Schnittstellenseiten und peripheriespezifische Seiten umfassen, wobei die Schnittstellenseiten und die peripheriespezifischen Seiten auf dem Inhaltsserver (10) gespeichert sind, und wobei eine Benutzernavigation durch Informationsseiten Schnittstellenseiten und peripheriespezifische Seiten auswählt, wobei der Browser (14) wirksam ist, um den Verknüpfungen zu diesen Schnittstellenseiten und peripheriespezifischen Seiten zu folgen.