DE102014000289A1

DE102014000289A1 - Webservervorrichtung, Steuerverfahren und Programm dafür

Info

Publication number: DE102014000289A1
Application number: DE102014000289.6A
Authority: DE
Inventors: Shinichi Uchikawa
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2013-01-28
Filing date: 2014-01-10
Publication date: 2014-07-31
Anticipated expiration: 2034-01-11
Also published as: JP6039446B2; CN103973764A; DE102014000289B4; US20140211248A1; CN103973764B; JP2014146114A

Abstract

Wenn ein Webservice eine Registrierungsanfrage an eine Webservervorrichtung übermittelt und wenn die gleiche URL wie die vom Webservice empfangene URL bereits in einer Webserviceverwaltungstabelle registriert ist, registriert die Webservervorrichtung den Webservice in der Webserviceverwaltungstabelle nach Bestimmung, dass die vom Webservice empfangene Bestimmungsbedingungserweiterung nicht die gleiche ist wie eine in der Webserviceverwaltungstabelle registrierte Bestimmungsbedingungserweiterung.

Description

HINTERGRUND DER ERFINDUNG
Gebiet der Erfindung
Der vorliegende Erfindungsgegenstand betrifft eine Webservervorrichtung zum Verarbeiten einer Anfrage zur Benutzung eines Internetdruckprotokollservices (IPP-Service für Internet Printing Protocol Service), ein Verfahren zur Steuerung der Webservervorrichtung, und ein Programm dafür.
Beschreibung des Standes der Technik
Die Anzahl der Systeme bei denen auf einem einzelnen Server mehrere Webservices, auch Webdienste genannt, betrieben werden hat sich kontinuierlich vergrößert. Zum Beispiel werden für einen Drucker netz-basierte (web-basierte) Druckdienste wie zum Beispiel ein Einrichtungeinstellungs- und Einrichtungverwaltungsdienst (im Weiteren bezeichnet mit Remote-UI für Remote User Interface, also eine fernsteuerbare Benutzeroberfläche), ein IPP-Service und Webservices auf Einrichtungen (WSD für Web Services an Devices) auf einem einzelnen Webserver betrieben.
Um mehrere Webservices auf einem einzelnen Server betreiben zu können, muss jedem Webservice eine spezifische URL (Uniform Resource Locator also eine Quelladresse) zugeordnet sein. Das kommt daher, dass wenn ein Webserver eine Anfrage zur Benutzung eines auf dem Webserver betriebenen Webservices empfängt, der Webserver basierend auf der in einer http-Kopfzeile, auch http-Header genannt, enthaltenen URL-Information bestimmen muss, zu welchem Webservice die Anfrage zum Ausführen übermittelt werden soll.
Entsprechend müssen die Webservices und die URL-Adressen miteinander auf einer Eins-zu-Eins-Basis verbunden sein. Daher ist es herkömmlicherweise notwendig, das System so zu konstruieren, dass eine eindeutige URL jedem der von einer Einrichtung zur Verfügung zu stellenden Webservices zugeordnet ist.
Darüberhinaus diskutiert die offengelegte japanische Patentanmeldung Nr. 2008-176789 eine Technik zum Registrieren von lediglich dem Anwendungspfand der URL, um die Belastungen des Webservers zu reduzieren.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einem Aspekt des vorliegenden Erfindungsgegenstands umfasst eine Webservervorrichtung eine Empfangseinheit eingerichtet zum Empfangen einer Registrierungsanfrage von einem Webservice sowie zum Empfangen einer URL und einer Bestimmungsbedingungserweiterung zum Identifizieren des Webservices, eine Registrierungseinheit eingerichtet zum Registrieren, falls die gleiche URL wie die empfangene URL schon in einer Webserviceverwaltungstabelle registriert ist, eines Zusammenhangs zwischen der empfangenen URL und der empfangenen Bestimmungsbedingungserweiterung sowie, in Verbindung damit, einer Funktion zum Aufrufen des Webservices in der Webserviceverwaltungstabelle als Information über den Webservice, der die Registrierungsanfrage übermittelt hat, nach Bestimmung, dass die empfangene Bestimmungsbedingungserweiterung nicht die gleiche ist, wie eine in der Webserviceverwaltungstabelle registrierte Bestimmungsbedingungserweiterung und eine Anfrageeinheit konfiguriert zum Aufrufen, falls eine Anfrage empfangen wird und der gleiche Zusammenhang wie ein in der Anfrage enthaltener Zusammenhang zwischen einer URL und einer Bestimmungsbedingungserweiterung in der Webserviceverwaltungstabelle registriert ist, eines Webservices zum Verarbeiten der Anfrage unter Verwendung der in Verbindung mit dem Zusammenhang registrierten Funktion.
Weitere Eigenschaften des vorliegenden Erfindungsgegenstands werden durch die folgende Beschreibung von beispielhaften Ausführungsformen unter Bezugnahme auf die beigefügten Abbildungen ersichtlich.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
ist ein Diagramm, welches die Konfiguration eines Systems gemäß einer ersten beispielhaften Ausführungsform des vorliegenden Erfindungsgegenstands zeigt.
ist ein Diagramm, welches eine Hardwarekonfiguration einer Webservervorrichtung zeigt.
ist ein Diagramm, welches die Konfiguration eines internen Moduls eines Webservers zeigt.
ist ein Diagramm, welches die Konfiguration eines internen Moduls eines Webservices zeigt.
, , und sind beispielhafte Webserviceverwaltungstabellen.
ist ein Flussdiagramm, welches eine Verarbeitung zeigt, die von einer Webserviceregistrierungseinheit ausgeführt wird.
ist ein Flussdiagramm, welches eine Verarbeitung zeigt, die von einer Webserviceregistrierungsverarbeitungseinheit ausgeführt wird.
ist ein Flussdiagramm, welches eine Verarbeitung zeigt, die von einer Webservicebestimmungseinheit ausgeführt wird.
, und sind Beispiele von Anfragedaten, die zum Webserver oder zu jedem Webservice übermittelt werden.
BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Es gibt Fälle, in denen wünschenswerterweise die gleiche URL für mehrere auf einem einzelnen Webserver betriebene Webservices zu verwenden ist. Zum Beispiel werden ein „http://Internetprotokolladress”-Pfad zum Angeben einer Bilderzeugungsvorrichtung und ein Hypertextransferprotokoll-Pfad (im Weiteren kurz mit http-Pfad für Hypertext Transfer Protocol path bezeichnet) mit einer einzelnen Internetprotokolladresse (IP-Adresse) zum Angeben eines Webservices definiert, um eine Benutzereingabe zu vereinfachen. Falls der Benutzer einen solchen Pfad kennt, kann der Benutzer den Dienst unter Verwendung eines Stammpfads („/”) verwenden. Das erlaubt es dem Benutzer, den Webservice einfach durch Merken der IP Adresse zu verwenden, wodurch eine hohe Benutzerfreundlichkeit erreicht wird. Somit wird eine einzelne URL für verschiedene Webservices verwendet, sodass der Benutzer sich nicht die URL eines jeden Webservices zu merken braucht.
Da eine solche Technik allerdings einen Eins-zu-Viele-Zusammenhang zwischen der URL und den Webservices bedeutet, kann der Webserver nicht identifizieren, zu welchem Webservice eine Anfrage, in Reaktion auf eine empfangene URL hin, übermittelt werden soll.
Der vorliegende Erfindungsgegenstand betrifft eine Webservervorrichtung, die es einem Webserver erlaubt, zu identifizieren, welcher Webservice aufzurufen ist entsprechend einer empfangenen http-Anfrage wenn mehrere Webservices, die die gleiche URL haben, auf einem einzelnen Webserver betrieben werden.
Verschiedene beispielhafte Ausführungsformen, Eigenschaften und Aspekte des Erfindungsgegenstands werden unten unter Bezugnahme auf die Abbildungen im Detail beschrieben.
In der ersten beispielhaften Ausführungsform des vorliegenden Erfindungsgegenstands wird eine Webserverfunktion beschrieben, die es einem Webserver erlaubt, einen Webservice zu identifizieren, der eine Anfrage verarbeiten soll auch wenn mehrere Webservices die gleiche URL haben.
ist ein Diagramm, welches eine Gesamtkonfiguration einer Webservervorrichtung 100 und einer Webclientvorrichtung 300 gemäß der ersten beispielhaften Ausführungsform zeigt.
In sind eine Webservervorrichtung 100 und eine Webclientvorrichtung 300 miteinander über ein Netzwerk 200 verbunden. Das Netzwerk 200 kann das Internet oder ein lokales Netzwerk (LAN für Local Area Network) sein.
Die Webservervorrichtung 100 enthält eine Kommunikationseinheit zur Netzwerkkommunikation, einen Webserver 120 zum Bereitstellen einer Webserverfunktion und Webservices 140, 150, 160 und 170. Jeder der Webservices 140, 150, 160 und 170 stellt durch Betrieb auf dem Webserver 120 einen Dienst bereit. „Dienst” oder auch „Service” bedeutet hier eine Funktion, die im Webservice wie dem oben beschriebenen Remote-UI-Service oder dem IPP-Service oder auch einem Dienst für netz-basierte verteilte Dokumentenerstellung und Versionsverwaltung (WebDAV-Service für web distributed authoring and versioning service) enthalten ist. Der Webserver empfängt eine http-Anfrage mittels http-Kommunikation und ordnet die Anfrage dem in der Anfrage angegebenen Webservice zu, sodass der Webservice den Dienst dafür bereitstellt. Jeder der Webservices 140, 150, 160 und 170 hat zum Beispiel eine Funktion entsprechend einer Allgemeinen-Vermittlungsrechner-Schnittstelle (CGI für Common Gateway Interface) oder einem Servlet. Jeder der Webservices 140, 150, 160 und 170 registriert die Webservicebestimmungsbedingung (Bestimmungsbedingungserweiterung, Bestimmungsbedingung-Erweiterung, oder erweiterte Bestimmungsbedingung) im Webserver 120. Wenn der Webserver 120 eine einer der Bestimmungsbedingungserweiterungen entsprechende Anfrage empfängt, ordnet der Webserver 120 die Anfrage dem der Bedinung entsprechenden Webservice zu. Dies ermöglicht dem Webservice die in der http-Anfrage angegebene Verarbeitung durchzuführen und den Dienst dafür bereitzustellen.
Die Webclientvorrichtung 300 enthält Webserviceclients 320, 330, 340 und 350. Die Webserviceclients 320, 330, 340 und 350 umfassen zum Beispiel einen Webbrowser zum Anzeigen von Hypertextauszeichnungssprachdaten (HTML-Daten für Hypertext Markup Language Data), einen WebDAV-Client zum Speichern/Beschaffen von Daten auf/von einem Speicher eines Webservices, einen WSD-Druckservice zum Drucken von Daten unten Benutzung eines von einem Webservice bereitgestellten Druckdienstes und einen http-Client. Jeder der Webserviceclients 320, 330, 340 und 350 hat eine Funktion, um mit einem Webservice unter Verwendung von http zu kommunizieren, um den Webservice zum Durchführen einer Verarbeitung anzufragen, ein Ergebnis der angefragten Verarbeitung zu empfangen und um das empfangene Ergebnis einem Benutzer bereitzustellen.
Um einen Webservice zum Durchführen einer Verarbeitung anzufragen, übermittelt jeder der Webserviceclients 320, 330, 340 und 350 eine http-Anfrage unter Verwendung einer Kommunikationseinheit 320 der Webclientvorrichtung 300 zum Webserver 120. Wenn der Webserver 120 die Anfrage empfängt, analysiert der Webserver 120 den http-Headerteil der Anfrage und bestimmt, ob die Anfrage einer der von den Webservices 140, 150, 160 und 170 registrierten Bestimmungsbedingungserweiterungen entspricht. Falls der Webserver 120 bestimmt, dass die Anfrage einer der registrierten Bestimmungsbedingungserweiterungen entspricht, führt der Webserver 120 eine Funktion zum Verarbeiten des entsprechenden Webservices aus. Wenn der Webserver 120 die Funktion zur Verarbeitung des Webservices ausführt, führt der Webservice die angefragte Verarbeitung gemäß des http-Vorgangs (HTTP Operation) oder des http-Körpers (HTTP Body part) der empfangenen Daten wie erforderlich durch, wodurch der Dienst bereitgestellt wird.
Die Webservervorrichtung 100 umfasst einen Festwertspeicher (ROM für Read Only Memory, Nur-Lese-Speicher) 102 und ein Festplattenlaufwerk (HDD für Hard Disk Drive) 103 wie in gezeigt. Eine Kommunikationseinheit 130, der Webserver 120 und die Webservices 140, 150, 160, und 170 in der Webservervorrichtung 100 sind im ROM 102 und auf der HDD 103 aufgezeichnet und werden von einer zentralen Prozessoreinheit (CPU für Central Processing Unit, Hauptprozessor) 101 ausgeführt.
ist ein Blockdiagramm, das ein Beispiel einer Hardwarekonfiguration der Webservervorrichtung 100 entsprechend der ersten beispielhaften Ausführungsform zeigt. Dises Diagramm zeigt die Webservervorrichtung 100, die eine Druckfunktion hat, als ein typisches Beispiel. Das bedeutet, die Webservervorrichtung ist hier ein Drucker. Die Webservervorrichtung kann eine Multifunktionsperipherieinrichtung mit einer Scanfunktion (nicht gezeigt) sein. Die Webservervorrichtung 100, die eine Speicherserverfunktion (storage server function) hat, umfasst die CPU 101.
Die CPU 101 steuert umfassend jede Einheit, die mit einem Systembus 104 verbunden ist, indem sie ein im ROM 102 oder in der HDD 103 gespeichertes Programm ausführt. Ein Direktzugriffsspeicher (RAM für Random Access Memory, Speicher mit wahlfreiem Zugriff) 111 fungiert als Hauptspeicher und Arbeitsbereich der CPU 101. Eine Steuereinheit 105 der Webservervorrichtung 100, die die Speicherserverfunktion hat, steuert einen Drucker 106, der als Druckengine dient, oder die HDD 103.
Eine Softwarekonfiguration der ersten beispielhaften Ausführungsform wird von der CPU 101 der Webservervorrichtung 100 realisiert, die ein im ROM 102 oder der HDD 103 gespeichertes Programm ausführt. Ein Nichtflüchtiger Direktzugriffsspeicher (NVRAM für Non-Volatile Random Access Memory) 107 speichert verschiedene Einstellwerte, um Arbeitsabläufe der Webservervorrichtung 100 zu definieren. Eine Konsolensteuereinheit 108 steuert eine Bedienkonsole 109, um verschiedene Informationen anzuzeigen und Anweisungen von einem Benutzer über die Bedienkonsole 109 zu empfangen. Eine Netzwerkschnittstellensteuereinheit (Netzwerk-I/F-Steuereinheit, I/F für Interface) 110 steuert Übertragung und Empfang von Daten zum und vom Netzwerk 200.
Die Webclientvorrichtung 300 hat ebenfalls die in gezeigte Hardwarekonfiguration. Jede in gezeigte Software kann arbeiten, wenn die CPU 101 ein im ROM 102 oder der HDD 103 gespeichertes Programm ausführt. In der ersten beispielhaften Ausführungsform wird angenommen, dass die Webclientvorrichtung 300 eine Informationsverarbeitungsvorrichtung wie zum Beispiel ein üblicher Personal Computer (PC) oder ein mobiles Endgerät wie ein Smartphone ist, und keine Bilderzeugungsfunktion wie zum Beispiel eine Druckfunktion besitzt. Somit handelt es sich bei der Webclientvorrichtung 300 um die Informationsverarbeitungsvorrichtung, die den Drucker 106 oder die Steuereinheit 105 nicht umfasst.
ist ein Diagramm, welches ein internes Modul des Webservers 120 zeigt. Der Webserver 120 umfasst eine Webserviceregistrierungsverarbeitungseinheit 121 zum Empfangen einer Webserviceregistrierungsanfrage von jedem der Webservices 140, 150, 160 und 170. Die Webserviceregistrierungsanfrage ist eine Anfrage, jeden der Webservices 140, 150, 160 und 170 im Webserver 120 zu registrieren. Wenn jeder der Webservices 140, 150, 160 und 170 registriert ist, kann jeder der registrierten Webservices 140, 150, 160 und 170 eine durch den Webserver 120 von einem Webserviceclient empfange Anfrage ausführen. Die Webserviceregistrierungsverarbeitungseinheit 121 hat eine Funktion zum Aufzeichnen einer Bestimmungsbedingungserweiterung und einer Verarbeitungsfunktion zum Aufrufen eines jeden der Webservices 140, 150, 160 und 170 in einer Webserviceverwaltungstabelle 122. Die Bestimmungsbedingungserweiterung kann zur Identifikation eines geeigneten Webservices verwendet werden, auch wenn einige der Webservices 140, 150, 160 und 170, die die Registrierungsanfrage übermittelt haben, die gleich URL haben.
Die Webserviceverwaltungstabelle 122 ist wie in den , , und gezeigt strukturiert. Für die erste beispielhafte Ausführungsform wird ein Beispiel beschrieben, wobei angenommen wird, dass die Webserviceverwaltungstabelle 122 erzeugt wird für jede Portnummer, auch Anschlussnummer genannt, an der der Webservice ausgeführt wird. Zum Beispiel, wenn Webservices an einer Transmissionssteuerprotokollanschlussnummer 80 (TCP-Portnummer für Transmission Control Protokol port number) und TCP-Portnummer 88 bereitgestellt werden, werden zwei Webserviceverwaltungstabellen 122 erzeugt, eine für TCP-Portnummer 80 und die andere für TCP-Portnummer 88. Die Erzeugung der Webserviceverwaltungstabelle 122 für jede Portnummer erlaubt es dem Webserver 120, einen geeigneten Webservice schneller zu finden.
Eine Anfrageempfangseinheit (http-Header-, auch http-Kopfzeilenempfangseinheit) 123 hat eine Funktion zum Empfangen eines http-Kopfzeilenteils (Headerteils) einer zum Webserver 120 über das Netzwerk übermittelten Anfrage. Eine Webservicebestimmungseinheit 124 hat eine Funktion zum Analysieren der von der Anfrageempfangseinheit 123 empfangenen http-Kopfzeileninformation (Headerinformation) und zum Identifizieren eines geeigneten Webservices anhand der übereinstimmenden in der Webserviceverwaltungstabelle 122 registrierten Bestimmungsbedingungserweiterung.
Eine Webserviceausführeinheit 125 führt den von der Webservicebestimmungseinheit 124 identifizierten Webservice aus. Die Webserviceausführeinheit 125 hat eine Funktion zum Ermöglichen von http-Kommunikation mit dem identifizierten Webservice. Diese http-Kommunikation ermöglicht zum Beispiel den Empfang eines http-Körpers und die Übermittlung einer http-Antwort gemäß einem http-Protokoll.
ist ein Diagramm, welches ein internes Modul des Webservices 140 zeigt. Eine Webserviceregistrierungseinheit 141 bestimmt ob der Webservice freigegeben oder gesperrt ist wenn der Webservice 140 aktiviert wird. Die Webserviceregistrierungseinheit 141 hat eine Funktion, um die Webserviceregistrierungsverarbeitungseinheit 121 zum Registrieren der URL, die Bestimmungsbedingungserweiterung des Webservices 140 und die Verarbeitungsfunktion für den Webservice 140 anzufragen, wenn der Webservice 140 freigegeben ist. Eine Webserviceverarbeitungseinheit 142 hat eine Funktion, um eine Verarbeitung des Webservices 140 durchzuführen. Insbesondere führt die Webserviceverarbeitungseinheit 142 die von der Webserviceausführeinheit 125 aufgerufene Serviceverarbeitungsfunktion aus. Die Webserviceverarbeitungseinheit 142 hat eine Funktion zum Durchführen einer Verarbeitung, die für jeden Webservice spezifisch ist.
ist ein Flussdiagramm, welches speziell von der Webserviceregistrierungseinheit 141 ausgeführte Verarbeitung zeigt. Die Webserviceregistrierungseinheit 141 ist in einer der Speichereinheiten, also dem RAM 111, dem ROM 102 und der HDD 103 gespeichert und wird von der CPU 101 ausführt. In Schritt S100 überprüft die Webserviceregistrierungseinheit 141 die Einstellungen des Webservices 140 wenn der Webservice 140 aktiviert wird und bestimmt ob der Webservice 140 freigegeben ist.
Wenn der Webservice 140 gesperrt ist (GESPERRT in Schritt S100) braucht keine Webserviceinformation im Webserver 120 registriert zu werden. Somit ist die Verarbeitung beendet, ohne die Webserviceinformation im Webserver zu registrieren. Wenn der Webservice 140 freigegeben ist (FREIGEGEBEN in Schritt S100), wird die Verarbeitung bei Schritt S101 fortgesetzt. In Schritt S101 überprüft die Webserviceregistrierungseinheit 141 die im Webserver zu registrierende Webserviceausführungbestimmungsbedingung. Beziehungsweise bestimmt die Webserviceregistrierungseinheit 141 ob lediglich URL-Information oder eine Bestimmungsbedingungserweiterung zusätzlich zur URL-Information zu registrieren ist. Die Bestimmungsbedingungserweiterung kann ein für den Webservice 140 spezifisches Attribut sein oder kann von einem Administrator für den Webservice 140 festgelegt werden.
Wenn lediglich die URL-Information registriert wird (JA in Schritt 101), dann registriert die Webserviceregistrierungseinheit 141 die URL-Information und die Webserviceverarbeitungsfunktion in Schritt S102. Wenn es eine Bestimmungsbedingungserweiterung zusätzlich zur URL-Information gibt (NEIN in Schritt S101), wird die Verarbeitung bei Schritt S103 fortgesetzt. In Schritt S103 registriert die Webserviceregistrierungseinheit 141 die URL-Information, die entsprechende Bestimmungsbedingungserweiterung und die Webserviceverarbeitungsfunktion im Webserver 120.
An dieser Stelle wird die oben beschriebene im Webserver 120 zu registrierende URL-Information näher beschrieben. Allgemein bezeichnet eine URL ein durch die Request for Comments (RFC) 1738 definiertes Format. Die im Webserver zu registrierende URL-Information, allerdings, stellt ein Protokoll (http/https), die TCP-Portnummer an der der Dienst bereitgestellt ist und URL-Pfandinformation anstelle der durch die RFC 1738 definierten Information dar.
Darüber hinaus kann jede in der http-Kopfzeile (http-Header) angegebene Information als Bestimmungsbedingungserweiterung verwendet werden. Zum Beispiel kann die Bestimmungsbedingungserweiterung ein http-Vorgang (http operation), eine Inhaltsart (Content-Type) oder ein Benutzeragent (User-Agent) einer http-Kopfzeile, oder eine mit einem „x-” beginnende http-Erweiterungskopfzeileninformation (http extension header information) als eine Anwendungserweiterung, wie sie durch RFC 822 definiert ist, sein. Wenn der Webservice 140 seine Bestimmungsbedingungserweiterung im Webserver 120 registriert, ruft der Webserver 120 den Webservice 140 nicht unter Verwendung der Verarbeitungsfunktion des Webservices 140 auf, auch wenn die URL-Information übereinstimmt, es sei denn die URL-Information und die Bestimmungsbedingungserweiterung stimmen beide überein. Alternative kann die Bestimmung auf Basis von zwei oder mehr Bestimmungsbedingungserweiterungen erfolgen. Wenn zum Beispiel bestimmt wird, dass ein anderer Webservice mit dem gleichen URL-Pfad auch den gleichen http-Vorgang hat, wird die Bestimmung weiterhin basierend auf der Inhaltsart durchgeführt. Somit kann der Webservice 140 eine Bestimmungsbedingungserweiterung im Webserver 120 zusätzlich zur URL registrieren.
Als nächstes wird eine Webserviceregistrierungsverarbeitung im Webserver 120 beschrieben.
Die Webserviceregistrierungsverarbeitungseinheit 121 ist in einer der Speichereinheiten, also dem RAM 111, dem ROM 102 und der HDD 103 gespeichert und wird von der CPU 101 ausführt. An dieser Stelle wird der in gezeigte, von der Webserviceregistrierungsverarbeitungseinheit 121 durchgeführte Verarbeitungsfluss unter Bezugnahme auf , , und beschrieben.
Zuerst wird beschrieben. zeigt den folgenden Zustand.
In der von gezeigten Webserviceverwaltungstabelle 122 sind der Remote-UI-Service 150 und der WebDAV-Service 170 als Dienste mit der TCP-Portnummer 80 registriert. Der Remote-UI-Service 150 ist lediglich mit „/” als URL-Pfad registriert. Der WebDAV-Service 170 ist lediglich mit „/share” als URL-Pfad registriert. Obwohl das http-Vorgangsfeld zur Registrierung einer Bestimmungsbedingungserweiterung durch den Webserver 120 bereitgestellt ist, ist das Feld für den Remote-UI-Service 150 und den WebDAV-Service 170 leer.
Das Flussdiagramm in wird unter der Annahme beschrieben, dass die Webserviceverwaltungstabelle 122 wie in gezeigt ist und die Webserviceregistrierungsverarbeitungseinheit 121 eine Anfrage zum Registrieren des http-Webservices 140 empfängt. Hier wird auch angenommen, dass der http-Webservice 140 eine Registrierungsanfrage unter Angabe der TCP-Portnummer als „80” und des URL-Pfands als „/” sowie des http-Vorgangs, der eine der Webservicebestimmungsbedingungen darstellt, als „POST” übermittelt hat.
In Schritt S200 überprüft die Webserviceregistrierungsverarbeitungseinheit 121, wenn eine Webserviceregistrierungsanfrage empfangen wird, die TCP-Portnummer der von der Webserviceregistrierungseinheit 141 angegebenen URL-Information.
In Schritt S201 bestimmt die Webserviceregistrierungsverarbeitungseinheit 121 ob es unter den Webserviceverwaltungstabellen 122 eine der angegebenen Portnummer entsprechende Webserviceverwaltungstabelle gibt. Gibt es keine der angegebenen Portnummer entsprechende Webserviceverwaltungstabelle (NEIN in Schritt S201), dann erzeugt in Schritt S206 die Webserviceregistrierungsverarbeitungseinheit 121 eine neue Webserviceverwaltungstabelle für die angegebene Portnummer. Anschließend, in Schritt S207, registriert die Webserviceregistrierungsverarbeitungseinheit 121 den angegebenen Dienstnamen, den URI-Pfand und die Bestimmungsbedingungserweiterung in der angelegten Webserviceverwaltungstabelle. Dann ist die Verarbeitung beendet. Falls vom Webservice 140 keine Bestimmungsbedingungserweiterung zusätzlich zur URI-Information angegeben wird, ist ein Feld für eine Bestimmungsbedingungserweiterung leer und wird ignoriert. Falls ein Webservice mit einem leeren Feld als Bestimmungsbedingungserweiterung registriert ist, wird, wenn zum Zeitpunkt eines Vergleichs die URL übereinstimmt, der Webservice identifiziert als der die übermittelte Anfrage verarbeitende Webservice. Die Konfiguration sieht derart aus, dass auch wenn Webservices mit einem leeren Feld als Bestimmungsbedingungserweiterung registriert sind und die in der Anfrage enthaltene Bestimmungsbedingungserweiterung nicht mit der registrierten Bestimmungsbedingungserweiterung übereinstimmt, einer der registrierten Webservices immer ausgeführt werden kann.
Hier gibt der IPP-Service 140 die TCP-Portnummer 80 an. Falls die Webserviceregistrierungsverarbeitungseinheit 121 bestimmt, dass es unter den Webserviceverwaltungstabellen 122 eine der TCP-Portnummer 80 entsprechende Webserviceverwaltungstabelle gibt (JA in Schritt S201), wird die in gezeigte Webserviceverwaltungstabelle gesucht. Nachdem die Webserviceverwaltungstabelle für TCP-Portnummer 80 gefunden ist, bestimmt die Webserviceregistrierungsverarbeitungseinheit 121 in Schritt S202 ob der gleiche URL-Pfad wie der der Webserviceregistrierungsanfrage in der Webserviceverwaltungstabelle registriert ist. Das heißt, dass die Webserviceregistrierungsverarbeitungseinheit 121 überprüft, ob ein Webservice mit dem gleichen URL-Pfad registriert ist. Falls ein Webservice mit dem gleichen URL-Pfad nicht registriert ist (NEIN in Schritt S202), registriert die Webserviceregistrierungsverarbeitungseinheit 121 in Schritt S207 Information eines neuen zu registrierenden Dienstes diesmal am Ende der Webserviceverwaltungstabelle. Da der IPP-Service 140 den URL-Pfad „/” hat, ist hier der URL-Pfad der gleiche wie der des an Nr. 1 der in gezeigten Webserviceverwaltungstabelle 122 registrierten Remote-UI-Services. Entsprechend bestimmt die Webserviceregistrierungsverarbeitungseinheit 121, dass der gleiche URL-Pfad wie der der Webserviceregistrierungsanfrage bereits registriert ist (JA in Schritt S202) und die Verarbeitung wird bei Schritt S203 fortgesetzt.
Falls der gleiche URL-Pfad registriert ist (JA in Schritt S202), führt die Webserviceregistrierungsverarbeitungseinheit 121 in Schritt S203 einen Vergleich unter Verwendung der Bestimmungsbedingungserweiterung durch. Da in diesem Beispiel der http-Vorgang als Bestimmungsbedingungserweiterung im Webserver 120 bereitgestellt ist, vergleicht die Webserviceregistrierungsverarbeitungseinheit 121 den http-Vorgang des Remote-UI-Services 150 mit dem vom IPP-Service 140 zu registrierenden http-Vorgang. Für den Remote-UI-Service 150 ist der http-Vorgang wie in gezeigt nicht angegeben. Andererseits gibt der IPP-Service 140 „POST” an. Als Ergebnis des Vergleichs stimmen die Bestimmungsbedingungserweiterung des IPP-Services 140 und des Remote-UI-Services 150 nicht miteinander überein (NEIN in Schritt S203) und die Registrierung des IPP-Services ist damit zugelassen. In solcher Weise wird der Webservice 140 in der Webserviceverwaltungstabelle 122 registriert, wenn die Webserviceregistrierungsverarbeitungseinheit 121 bestimmt, dass die empfange Bestimmungsbedingungserweiterung nicht mit der mit der gleichen URL zusammenhängend in der Webserviceverwaltungstabelle 122 registrierten Bestimmungsbedingungserweiterung übereinstimmt. Wenn der Webservice 140 in der Webserviceverwaltungstabelle registriert worden ist, sind die URL, die entsprechende Bestimmungsbedingungserweiterung, die Webserviceverarbeitungsfunktion und der Webservicename miteinander wie in gezeigt in Verbindung gesetzt. Wenn als Ergebnis des Vergleichs der Bestimmungsbedingungserweiterungen die Bestimmungsbedingungserweiterung des IPP-Services 140 und des Remote-UI-Services 150 miteinander übereinstimmen (JA in Schritt S203), wird die Verarbeitung bei Schritt S204 fortgesetzt. In Schritt S204 registriert die Webserviceregistrierungsverarbeitungseinheit 121 den Webservice 140 nicht und die Verarbeitung ist beendet.
Als nächstes wird eine Verarbeitung zum Überprüfen des Registrierungsrangs (der Registrierungspriorität) von Webservices und zur anschließenden eigentlichen Registrierung des Webservices 140 in der Webserviceverwaltungstabelle 122 beschrieben. In Schritt S205 vergleicht die Webserviceregistrierungsverarbeitungseinheit 121 die Anzahl von Bestimmungsbedingungserweiterungen des gegenwärtig neu zu registrierenden Webservices 140 mit der Anzahl der Bestimmungsbedingungserweiterungen des registrierten Webservices 150 mit dem gleichen URL-Pfad. Dieser Vergleich wird gemacht, da, wenn die Webservicebestimmungseinheit 124 nach einem einer Bestimmungsbedingungserweiterung einer Anfrage entsprechenden Webservice sucht, die Webservicebestimmungseinheit 124 die Webservices in der Webserviceverwaltungstabelle 122 in aufsteigender Reihenfolge der Registrierungsnummer überprüft, um zu bestimmen, ob es einen der Anfrage entsprechenden Webservice gibt. Daher muss ein Webservice mit einer strengeren Bedingung mit einer niedrigeren Registrierungsnummer in der Webserviceverwaltungstabelle 122 registriert sein als ein Webservice mit einer weniger strengen Bedingung. Andernfalls könnte nach einem Webservice mit einer weniger strengen Bedingung zuerst gesucht werden, da die Anzahl der Bestimmungsbedingungserweiterungen von diesem kleiner ist als die von einem Webservice mit strengerer Bedingung. Das könnte zur Folge habe, dass der Webservice mit der strengeren Bedingung aufgrund der größeren Anzahl an Bestimmungsbedingungserweiterungen nicht durchsucht wird.
Basierend auf dem Vergleich ist eine Bestimmungsbedingungserweiterung für den IPP-Service 140 festgelegt wohingegen keine Bestimmungsbedingungserweiterung für den Remote-UI-Service 150 festgelegt ist. In Schritt S209 wird der IPP-Service 140 an der Registrierungsnummer 1 eingefügt und registriert, da der IPP-Service 140 den höheren Rang (die höhere Priorisierung) bei der Suche erhalten muss als der Remote-UI-Service 150. Als Ergebnis sind die Registrierungsnummern des Remote-UI-Services 150 und des WebDAV-Services 170 in der in gezeigten Tabelle um eins von den Registrierungsnummern in der in gezeigten Tabelle verschoben. Falls die Anzahl der Bestimmungsbedingungserweiterungen des neu zu registrierenden Webservices 140 kleiner oder gleich der des registrierten Webservices 150 ist (NEIN in Schritt S205), wird die Verarbeitung bei Schritt S208 fortgesetzt. In Schritt S208 registriert die Webserviceregistrierungsverarbeitungseinheit 121 den Webservice 140 mit einer Registrierungsnummer, die der Registrierungsnummer des Webservices 150 mit der gleichen URL folgt.
An dieser Stelle wird ein Beispiel beschrieben, bei dem die Webserviceverwaltungstabelle wie in ist und der http-Service 140 zu registrieren ist. In sind der WSD-Druckservice 160, der Remote-UI-Service 150 und der WebDAV-Service 170 als Dienste mit der TCP-Portnummer 80 in der Webserviceverwaltungstabelle 122 registriert. Der WSD-Druckservice 160 und der Remote-UI-Service 150 sind mit „/” als URL-Pfad registriert, wohingegen der WebDAV-Service lediglich mit „/share” als URL-Pfad registriert ist. In der in gezeigten Webserviceverwaltungstabelle werden das http-Vorgangsfeld und das Inhaltsart-Feld als Bestimmungsbedingüngserweiterungen vom Webserver 120 bereitgestellt. Für den WSD-Druckservice 160 sind „POST” und „application/soap + xml” als http-Vorgang beziehungsweise Inhaltsart angegeben. Für den Remote-UI-Service 150 und den WebDAV-Service ist keine Bestimmungsbedingungserweiterung angegeben.
In einem solchen Zustand wird angenommen, dass der http-Webservice (IPP-Service) 140 eine Registrierungsanfrage unter Angabe der TCP-Portnummer als „80”, des URL-Pfads als „/”, des http-Vorgangs als „POST” und der Inhaltsart als „application/ipp” übermittelt hat. In diesem Fall vergleicht die Webserviceregistrierungsverarbeitungseinheit 121 in Schritt S205 des in gezeigten Flussdiagramms die Anzahl der Bestimmungsbedingungserweiterungen des neu zu registrierenden Webservices 140 mit der der mit dem gleichen URL-Pfad registrierten Webservices 150 und 160. Als Ergebnis ist, da der http-Vorgang und der Inhaltstyp als Bestimmungsbedingungserweiterungen für den IPP-Service 140 als auch für den WSD-Druckservice 160 angegeben sind, die Anzahl der Bestimmungsbedingungserweiterungen zueinander gleich. Folglich wird der IPP-Service 140 mit einer Registrierungsnummer, die der Registrierungsnummer des WSD-Druckservices folgt, registriert und dadurch wird die Webserviceverwaltungstabelle 122 wie in aktualisiert.
Zuletzt wird eine von der Webservicebestimmungseinheit 124 ausgeführte Verarbeitung unter Bezugnahme auf beschrieben. Die Webservicebestimmungseinheit 124 ist in einer der Speichereinheiten, also dem RAM 111, dem ROM 102 und der HDD 103 gespeichert und wird von der CPU 101 ausgeführt. Die Webservicebestimmungseinheit 124 hat eine Funktion; um Anfragen den entsprechenden Webservices zuzuordnen.
In Schritt S300, wenn eine Anfrage an einen Webservice empfangen wird, fordert die Anfrageempfangseinheit 123 die Webservicebestimmungseinheit auf, den Webservice zu bestimmen. Die Webservicebestimmungseinheit 124 erhält von der Anfrageempfangseinheit 123 die Empfang-TCP-Portnummer, an der die http-Anfrage empfangen wurde und die http-Kopfzeileninformation der empfangenen Anfrage. Die Webservicebestimmungseinheit 124 analysiert die http-Kopfzeileninformation.
In Schritt S301 überprüft die Webservicebestimmungseinheit 124, ob es in der Webserviceverwaltungstabelle 122 eine der Empfang-TCP-Portnummer entsprechende Webserviceverwaltungstabelle gibt. Falls es keine der TCP-Portnummer entsprechende Webserviceverwaltungstabelle gibt (NEIN in Schritt S301), wird die Verarbeitung bei Schritt S307 fortgesetzt. In Schritt S307 bestimmt die Webservicebestimmungseinheit 124, dass der entsprechende Webservice nicht existiert. Andererseits, falls es eine der Empfang-TCP-Portnummer entsprechende Webserviceverwaltungstabelle gibt (JA in Schritt S301), wird die Verarbeitung bei Schritt S302 fortgestzt. In Schritt S302 legt die Webservicebestimmungseinheit 124 eine Dienstsuchstartposition auf die oberste der Registrierungsnummern (d. h. die Registrierungsnummer 1) in der nachgewiesenen Webserviceverwaltungstabelle.
In Schritt S303 sucht, ausgehend von der Suchstartposition in der ausgewählten Webserviceverwaltungstabelle, die Webservicebestimmungseinheit 124 nach einem registrierten Dienst, der den gleichen URL-Pfad wie die empfangene http-Anfrage hat. Falls es keinen registrierten Dienst mit dem gleichen URL-Pfad gibt, bestimmt die Webservicebestimmungseinheit 124 in Schritt S307, dass es keinen Webservice gibt, der die Anfrage verarbeiten kann. Anschließend ist die Verarbeitung beendet. Falls die Webservicebestimmungseinheit 124 einen registrierten Dienst mit dem gleichen URL-Pfad nachgewiesen hat (JA in Schritt S303), wird die Verarbeitung bei Schritt S304 fortgesetzt. In Schritt S304 überprüft die Webservicebestimmungseinheit 124 ob die Bestimmungsbedingungserweiterung des nachgewiesenen Webservices mit der Bestimmungsbedingungserweiterung der übermittelten Anfrage übereinstimmt. Falls diese Bestimmungsbedingungserweiterungen nicht miteinander übereinstimmen (NEIN in Schritt S304), wird die Verarbeitung bei Schritt S305 fortgesetzt. In Schritt S305 legt die Webservicebestimmungseinheit 124 eine Suchstartposition in der Webserviceverwaltungstabelle fest auf die Position des Webservices mit einer Registrierungsnummer, die der Registrierungsnummer des Webservices folgt, für den gegenwärtig keine Übereinstimmung bestimmt wurde. Dann kehrt die Verarbeitung zu Schritt S303 und Schritt S304 zurück, sodass die Webservicebestimmungseinheit 124 die Suche nach einem Webservice mit der gleichen URL und übereistimmender Bestimmungsbedingungserweiterung fortsetzt. Falls die Webservicebestimmungseinheit 124 bestimmt, dass die Bestimmungsbedingungserweiterung mit der übermittelten Bestimmungsbedingungserweiterung übereinstimmt (JA in Schritt S304), bestimmt die Webservicebestimmungseinheit 124 in Schritt S306, dass der der Anfrage entsprechende Webservice gefunden wurde.
Jetzt wird ein spezifisches Beispiel einer Verarbeitung der Webservicebestimmungseinheit 124 mit Bezug zum in gezeigten Flussdiagramm beschrieben. In dieser Verarbeitung übermittelt die Webclientvorrichtung 300 eine Anfrage an den Webserver 120 und die Webservicebestimmungseinheit 124 gibt den entsprechenden Webservice an. Es wird hier angenommen, dass die Webserviceverwaltungstabelle 122 wie in gezeigt ist. Die in gezeigte Systemkonfiguration und in , und gezeigte Beispiele für Anfragedaten an den Webservice werden für diese Verarbeitung verwendet.
Damit ein Benutzer sich mit dem Webservice (dem Remote-UI-Service 150) verbinden kann, gibt der Benutzer die URL-Information des Remote-UI-Services 150 in ein URL-Eingabefeld des Webserviceclients 350 (im Weitern als Webbrowser bezeichnet) ein. Die einzugebende URL-Information ist zum Beispiel http://172.24.29.162/. Diese URL-Information muss nicht notwendigerweise in das Eingabefeld des Webbrowsers 350 eingegeben werden. Die URL-Information kann durch Auswahl einer im Webbrowser als Lesezeichen registrierten Information eingegeben werden. Die Information „172.24.29.162” gibt die IP-Adresse der Webservervorrichtung an. Die Kombination von „http://” und der IP-Adresse ermöglicht jedem der Webserviceclients 320, 330, 340 und 350 auf den Webserver 120 zuzugreifen. Der Webbrowser 350 identifiziert den Webserver 120 basierend auf der eingegebenen URL-Information und übermittelt eine in gezeigte http-Anfrage zum Erhalt von HTML-Daten. In diesem Fall enthält die http-Anfrage lediglich eine http-Kopfzeile, das heißt, ein http-Körper ist nicht in der http-Anfrage enthalten.
Die Anfrageempfangseinheit 123 fordert, wenn die in gezeigte http-Kopfzeile der Anfragedaten empfangen wird, die Webservicebestimmungseinheit 124 auf, den entsprechenden Webservice zu identifizieren. Die Webservicebestimmungseinheit 124 identifiziert den Webservice basierend auf der in gezeigten Webservicebestimmungsverarbeitung. Entsprechend der Anfrage (9A) des Webbrowsers 350 ist der URL-Pfad „/” und der http-Vorgang „GET”. Daher bestimmt die Webservicebestimmungseinheit 124 diese Anfrage als eine Verarbeitungsanfrage an den Remote-UI-Service 150 mit der Registrierungsnummer 2 als Ergebnis der Suche in der in gezeigten Webserviceverwaltungstabelle 122. Entsprechend wird der Remote-UI-Service 150 ausgeführt und ein Verarbeitungsergebnis davon wird dem Webbrowser 350 als Antwort bereitgestellt. Der Webbrowser 350 erhält eine HTML-Datei als das Verarbeitungsergebnis vom Remote-UI-Service 150 und zeigt die erhaltene HTML-Datei an.
Ein weiteres spezifisches Beispiel wird beschrieben, in dem sich ein Benutzer mit dem IPP-Service 140 verbindet. Der IPP-Service 140 ist das Internetdruckprotokoll (IPP für Internet Printing Protocol) und die Versionen 1.0, 1.1, 2.0, 2.1 und 2.2 sind von der RFC definiert. Das IPP definiert Befehle zum Überprüfen des Zustandes oder der Fähigkeiten eines Druckers, zum Ausgeben einer Anweisung zum Drucken eines angegebenen Dokuments und zum Überprüfen eines Auftragszustandes. Diese Befehle sind im http-Körper gespeichert. Mit anderen Worten, der Vorgang des IPP kann nicht mit der http-Kopfzeile identifiziert werden.
Wenn der Benutzer den IPP-Service 140 verwendet, um Druckerfähigkeitsinformation zu überprüfen, muss der Nutzer die URL des IPP-Services 140 im IPP-Client 340 angeben. Die URL des IPP-Services 140 kann direkt vom Benutzer angegeben werden. Die URL des IPP-Services 140 kann auch über ein Netzwerk mittels einer Servicesuchtechnik wie mDNS (multicast Domain Name System, also ein Multicast-Bereichsnamensystem) und SLP (Service Location Protocol, also ein Dienststandortprotokoll) gesucht werden. Basierend auf dem Suchergebnis kann die URL des IPP-Services 140 erhalten werden.
Wenn der Benutzer nach der URL-Information des IPP-Services 140 sucht und diese erhält oder die URL direkt im IPP-Client 340 eingibt, ist der Benutzer mit der angegeben URL verbunden. Es wird hier angenommen, dass die URL zum Beispiel http://172.24.29.162/ ist. Diese URL ist die gleiche wie die des oben beschriebenen Remote-UI-Services 150. Eine Registrierung des Webservices 140 in diesem Zustand bewirkt, dass der Webservice 140 und der Remote-UI-Service 150 beide mit der gleichen URL registriert werden. Dann übermittelt der IPP-Client 340 eine Anfrage, die http-Kopfzeileninformation und einen in gezeigten http-Körper enthält, der einen die Details der Anfrage an den IPP-Service 140 ergebenden Befehl umfasst.
Die Anfrageempfangseinheit 123 fordert die Webservicebestimmungseinheit 124 auf, wenn die http-Kopfzeile der in gezeigten Anfragedaten empfangen wird, den entsprechenden Webservice zu identifizieren. Die Webservicebestimmungseinheit 124 identifiziert den Webservice basierend auf der in gezeigten Webservicebestimmungsverarbeitung. Entsprechend der Anfrage ( ) vom Webbrowser 350 ist der URL-Pfad „/” und der http-Vorgang „POST”. Daher bestimmt die Webservicebestimmungseinheit 124 die Anfrage als eine Verarbeitungsanfrage an den IPP-Service 140 mit der Registrierungsnummer 1 basierend auf einer Suche in der in gezeigten Webserviceverwaltungstabelle 122. Dann wird der IPP-Service 140 ausgeführt.
Der IPP-Service überprüft dazu die Details der Anfrage durch Empfangen der im http-Körper enthaltenen IPP-Anfragedaten.
zeigt ein Datenformat der in gezeigten IPP-Anfragedaten.
Die IPP-Anfrage ist durch die RFC 2910 definiert und eine Anweisung an den IPP-Service 140 wird im Vorgang-ID-Feld (Operation-ID-Feld) angegeben. Eine Anweisung an den IPP-Service ist zum Beispiel eine Druck-Auftrag-Anfrage (Print-Job-Anfrage) zum Durchführen eines Druckvorgangs oder eine Erhalte-Drucker-Merkmale-Anfrage (Get-Printer-Attributes-Anfrage) zum Erhalten von Druckermerkmalen. „0x0002” im Operation-ID-Feld angegeben bezeichnet die Druck-Auftrag-Anfrage, wohingegen „0x000B” im Operation-ID-Feld angegeben die Erhalte-Drucker-Merkmale-Anfrage bezeichnet.
Der IPP-Service 140 führt die durch den im Operation-ID-Feld enthaltenen Befehl angegebene Anweisung aus, wenn die Anfragedaten im in gezeigten Format empfangen werden. Wenn zum Beispiel die Anweisung die Erhalte-Drucker-Merkmale-Anfrage zum Erhalten von Druckermerkmalen ist, antwortet der IPP-Service 140 dem IPP-Client 340 mit der Druckerfähigkeitsinformation. Wenn die Anweisung die Druck-Auftrag-Anfrage ist, empfängt der IPP-Service 140 im Datenfeld der Anfrage enthaltene Druckdaten und veranlasst den Drucker 106, Drucken basierend auf den Druckdaten durchzuführen.
Wenn der IPP-Service 140 die von den in gezeigten IPP-Anfragedaten angegebene Verarbeitung fertigstellt, übermittelt der IPP-Service 140 eine Antwort auf die angeforderte Verarbeitung an den IPP-Client 340 durch Speichern der Antwort im http-Körper in einem dem IPP-Standard gemäßen Format.
Der IPP-Client 340 erhält ein Ergebnis der Anfrage durch die im http-Körper der empfangenen Antwort gespeicherten Daten und beendet die Kommunikation mit dem IPP-Service 140.
Gemäß der ersten beispielhaften Ausführungsform, wie oben beschrieben, kann, auch wenn mehrere Webservices mit der gleichen URL auf einem einzelnen Webserver betrieben werden, der Webserver den aufzurufenden Webservice basierend auf einer empfangenen http-Anfrage identifizieren. Da die http-Anfrage abhängig vom die Anfrage übermittelnden Webserviceclient unterschiedlich sein kann, kann der Webserver den Webservice unter den mehreren Webservices mit der gleichen URL identifizieren. Folglich muss sich der Benutzer nur eine URL merken. Das lässt es zu, eine Vielfalt von Webservices auszuführen und dabei die Benutzerfreundlichkeit zu erhalten.
Eine andere beispielhafte Ausführungsform des vorliegenden Erfindungsgegenstands wird im Folgenden beschrieben. Die oben beschriebene beispielhafte Ausführungsform des vorliegenden Erfindungsgegenstands wird verwirklicht durch Ausführen der Verarbeitung indem Software (ein Programm) zum Implementieren der Funktionen der oben beschriebenen Ausführungsform an ein System oder eine Vorrichtung durch ein Netzwerk oder verschiedene Speichermedien geliefert wird und von einem Computer (oder einer CPU oder einem Mikroprozessor (MPU für Micro-Processing Unit)) in dem System oder der Vorrichtung ausgeführt wird.
Daher kann, auch wenn mehrere Webservices mit der gleichen URL auf einem einzelnen Webserver betrieben werden, der Webserver basierend auf einer empfangenen http-Anfrage identifizieren, welcher Webservice aufzurufen ist.
Während die vorliegende Erfindung unter Bezugnahme auf beispielhafte Ausführungsformen beschrieben wurde, versteht sich, dass die Erfindung nicht auf die offenbarten beispielhaften Ausführungsformen beschränkt ist. Der Schutzumfang der beigefügten Ansprüche umfasst in seiner breitesten Auslegung sämtliche Modifikationen und äquivalenten Strukturen sowie Funktionsweisen.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

JP 2008-176789 [0005]

Zitierte Nicht-Patentliteratur

(RFC) 1738 [0040]
RFC 822 [0041]
http://172.24.29.162/ [0060]
http://172.24.29.162/ [0064]
RFC 2910 [0068]

Claims

Webservervorrichtung umfassend: eine Empfangseinheit eingerichtet zum Empfangen einer Registrierungsanfrage von einem Webservice sowie zum Empfangen einer URL und einer Bestimmungsbedingungserweiterung, verwendet zum Identifizieren des Webservices; eine Registrierungseinheit eingerichtet zum Registrieren, falls die gleiche URL wie die empfangene URL schon in einer Webserviceverwaltungstabelle registriert ist, eines Zusammenhangs zwischen der empfangenen URL und der empfangenen Bestimmungsbedingungserweiterung sowie, in Verbindung damit, einer Funktion zum Aufrufen des Webservices in der Webserviceverwaltungstabelle als Information über den Webservice, der die Registrierungsanfrage übermittelt hat, nach Bestimmung, dass die empfangene Bestimmungsbedingungserweiterung nicht die gleiche ist, wie eine in der Webserviceverwaltungstabelle registrierte Bestimmungsbedingungserweiterung; und eine Anfrageeinheit konfiguriert zum Aufrufen, falls eine Anfrage empfangen wird und der gleiche Zusammenhang wie ein in der Anfrage enthaltener Zusammenhang zwischen einer URL und einer Bestimmungsbedingungserweiterung in der Webserviceverwaltungstabelle registriert ist, eines Webservices zum Verarbeiten der Anfrage unter Verwendung der in Verbindung mit dem Zusammenhang registrierten Funktion.
Webservervorrichtung nach Anspruch 1, wobei die Registrierungseinheit den Webservice, der die Registrierungsanfrage übermittelt hat, nicht registriert, falls die Registrierungseinheit bestimmt, dass die erhaltene Bestimmungsbedingungserweiterung die gleiche ist wie die in der Webserviceverwaltungstabelle registrierte Bestimmungsbedingungserweiterung.
Webservervorrichtung nach Anspruch 1, wobei, wenn die Registrierungseinheit den Webservice, der die Registrierungsanfrage übermittelt hat, registriert, die Registrierungseinheit ein Prioritätsniveau des Webservices bestimmt und den Webservice in der Webserviceverwaltungstabelle entsprechend dem Prioritätsniveau registriert.
Webservervorrichtung nach Anspruch 1, wobei, wenn die Registrierungseinheit den Webservice, der die Registrierungsanfrage übermittelt hat, registriert, die Registrierungseinheit die Anzahl der in der Webserviceverwaltungstabelle registrierten Bestimmungsbedingungserweiterungen, die mit der gleichen wie der empfangenen URL zusammenhängen, mit der Anzahl der empfangenen Bestimmungsbedingungserweiterungen vergleicht und, falls die Anzahl der empfangenen Bestimmungsbedingungserweiterungen größer ist, die Registrierungseinheit den Webservice, der die Registrierungsanfrage übermittelt hat, in der Webserviceverwaltungstabelle mit einem höheren Prioritätsniveau registriert.
Webservervorrichtung nach Anspruch 1, wobei die Webserviceverwaltungstabelle für jede Portnummer gespeichert wird, und wobei die Registrierungseinheit eine Portnummer des Webservices basierend auf der empfangenen URL identifiziert und den Webservice in der Webserviceverwaltungstabelle für die identifizierte Portnummer registriert.
Webservervorrichtung nach Anspruch 1, wobei der Webservice, der die Registrierungsanfrage übermittelt hat, ein Internetdruckprotokollservice (IPP-Service) ist.
Webservervorrichtung nach Anspruch 1, wobei die Webservervorrichtung ein Drucker ist.
Verfahren zur Steuerung einer Webservervorrichtung, wobei das Verfahren umfasst: Empfangen einer Registrierungsanfrage von einem Webservice sowie Empfangen einer URL und einer Bestimmungsbedingungserweiterung, verwendet zum Identifizieren des Webservices; Registrieren eines Zusammenhangs zwischen der empfangenen URL und der empfangenen Bestimmungsbedingungserweiterung sowie, in Verbindung damit, einer Funktion zum Aufrufen des Webservices als Information über den Webservice, der die Registrierungsanfrage übermittelt hat, in einer Webserviceverwaltungstabelle, falls die gleiche URL wie die empfangene URL schon in dieser registriert ist, nach Bestimmung, dass die empfangene Bestimmungsbedingungserweiterung nicht die gleiche ist wie eine in der Webserviceverwaltungstabelle registrierte Bestimmungsbedingungserweiterung; und Aufrufen eines Webservices, falls eine Anfrage empfangen wird und der gleiche Zusammenhang wie ein in der Anfrage enthaltener Zusammenhang zwischen einer URL und einer Bestimmungsbedingungserweiterung in der Webserviceverwaltungstabelle registriert ist, zur Verarbeitung der Anfrage unter Verwendung der in Verbindung mit dem Zusammenhang registrierten Funktion.
Verfahren nach Anspruch 8, weiterhin umfassend ein Nicht-Registrieren des Webservices, der die Registrierungsanfrage übermittelt hat, falls die empfangene Bestimmungsbedingungserweiterung die gleiche ist wie die in der Webserviceverwaltungstabelle registrierte Bestimmungsbedingungserweiterung.
Verfahren nach Anspruch 8, weiterhin umfassend, wenn der Webservice, der die Registrierungsanfrage übermittelt hat, registriert wird, ein Bestimmen eines Prioritätsniveaus des Webservices und Registrieren des Webservices entsprechend dem Prioritätsniveau.
Verfahren nach Anspruch 8, weiterhin umfassend, wenn der Webservice, der die Registrierungsanfrage übermittelt hat, registriert wird, ein Vergleichen der Anzahl der Bestimmungsbedingungserweiterungen, die zusammenhängend mit der gleichen URL wie der empfangenen URL in der Webserviceverwaltungstabelle registriert sind, mit der Anzahl der empfangenen Bestimmungsbedingungserweiterungen und, falls die Anzahl der empfangenen Bestimmungsbedingungserweiterungen größer ist, ein Registrieren des Webservices, der die Registrierungsanfrage übermittelt hat, in der Webserviceverwaltungstabelle mit einem höheren Prioritätsniveau.
Verfahren nach Anspruch 8, wobei die Webserviceverwaltungstabelle für jede Portnummer gespeichert wird, und wobei das Verfahren weiterhin umfasst, Identifizieren einer Portnummer des Webservices basierend auf der empfangenen URL und Registrieren des Webservices in der Webserviceverwaltungstabelle für die identifizierte Portnummer.
Verfahren nach Anspruch 8, wobei der Webservice, der die Registrierungsanfrage übermittelt hat, ein Internetdruckprotokollservice (IPP-Service) ist.
Verfahren nach Anspruch 8, wobei die Webservervorrichtung ein Drucker ist.
Speichermedium, das ein Programm speichert, das eine Webservervorrichtung veranlasst, das Verfahren nach Anspruch 8 auszuführen.