-
Beschreibung
der Erfindung
-
Diese
Erfindung bezieht sich auf ein Verfahren zum Vermitteln von Netzwerkdiensten
und auf einen Vermittler zum Vermitteln von Netzwerkdiensten.
-
Hintergrund
der Erfindung
-
Die
Verbindung von Computern und anderen Vorrichtungen, um Netzwerke
zu bilden, ist hinreichend bekannt und weit verbreitet. Derartige
Netzwerke liefern beträchtliche
Vorteile in Bezug darauf, Computer und ihre Benutzer zu befähigen, zu
kommunizieren und auf Ressourcen wie z. B. Informationsspeicher,
Drucker usw. zuzugreifen und dieselben gemeinsam zu verwenden. Eine
Anfrage besteht darin, dass sich eine Entität wie z. B. ein Computer oder
eine andere Vorrichtung, der bzw. die mit dem Netzwerk verbunden
ist, anderer Netzwerkentitäten,
mit denen er bzw. sie kommunizieren kann und deren Fähigkeiten
zur Nutzung zur Verfügung
stehen, bewusst sein sollte oder in der Lage sein sollte, dieselben
zu identifizieren.
-
In
Bezug auf relativ kleine und stabile Netzwerke ist es bekannt, jede
Entität
mit einer Netzwerkadresse zu versehen und diese Netzwerkadresse
anderen Entitäten
zur Verfügung
zu stellen. Beispielsweise kann ein Personal-Computer manuell mit
der Netzwerkadresse eines Druckers versehen werden und eingestellt werden,
alle Druckeraufträge
an diese Netzwerkadresse zu senden. Diese Technik eignet sich jedoch
nicht für große Netzwerke
mit einer sehr großen
Anzahl von mit dem Netzwerk verbundenen Entitäten, und auch nicht für Ad-hoc-
oder veränderbare
Netzwerke.
-
Es
wurden bereits eine Anzahl von Protokollen oder Techniken entwickelt,
um Netzwerkentitäten
zu befähigen,
andere Entitäten
mit wünschenswerten
Charakteristika zu identifizieren. Beispielsweise möchte ein Personal-Computer
eventuell einen Farbdrucker identifizieren, der in der Lage ist,
eine bestimmte Art von Graphikdatei zu drucken. Die Techniken können allgemein
als „Nachschlage"-Techniken charakterisiert
werden, bei denen ein Verzeichnis von Entitäten und ihren zugeordneten
Fähigkeiten
unterhalten wird, und als „Entdeckung", wobei eine Entität aktiv
eine andere Entität,
die eine gewünschte
Fähigkeit
aufweist, ausfindig macht oder sucht. Ferner kennt man die Verwendung
einer Kombination von „Nachschlage"- und „Entdeckung"-Techniken.
-
Da
die Terminologie auf diesem technischen Gebiet bei Protokollen und
Anwendungen nicht einheitlich ist, weisen die folgenden Begriffe
in dem vorliegenden Dokument die folgende Bedeutung auf:
„Dienst" – bezieht sich auf eine Funktion
oder Ressource, die durch eine Netzwerkentität bereitgestellt wird und über das
Netzwerk anderen Entitäten
zur Verfügung
steht. Es muss ganz klar keine Eins-zu-Eins-Beziehung zwischen Diensten
und Entitäten
vorliegen. Beispielsweise wäre
ein Kombinationsgerät
aus Scanner, Drucker und Faxgerät
eine einzige Entität,
liefert jedoch drei verschiedene Dienste.
„Entität" – bezieht
sich auf jegliche Vorrichtung oder Anwendung, die über ein
Netzwerk einen Dienst bereitstellt und/oder auf Dienste zugreift.
Somit kann eine Entität
eine physische Vorrichtung, z. B. ein Drucker, oder auch eine Software-Anwendung
sein.
„Client" – bezieht sich auf eine Entität, die auf
einen Dienst zugreifen oder einen solchen aufrufen möchte.
„Vermittler,
vermitteln" – bedeutet
als Verb, einen Dienst anzubieten, der durch eine andere Netzwerkentität ausge führt wird,
und als Hauptwort bezieht es sich auf jegliche Entität, die einen
durch eine andere Entität
ausgeführten
Dienst anbietet.
-
Bei
der „Nachschlage"-Technik unterhält ein Vermittler
ein Verzeichnis von Diensten, die über ein Netzwerk verfügbar sind.
Um einen benötigten
Dienst zu finden, sendet ein Client eine Anfrage an den Vermittler, die
die benötigten
Fähigkeiten
identifiziert. Anschließend
durchsucht der Vermittler das Verzeichnis nach einem Dienst, der
mit den benötigten
Fähigkeiten übereinstimmt,
und beantwortet die Anfrage. Beispiele von Protokollen, die diese
Technik verwenden, sind der LDAP- und der CORBA-Händlerdienst
(LDAP = lightweight directory access protocol, Leichtverzeichniszugriffsprotokoll).
Derartige Protokolle sind jedoch rechenintensiv und schwierig zu
pflegen und zu installieren. Sie weisen jedoch den Vorteil auf,
dass sie in der Lage sind, auf spezifische Anfragen bezüglich einer
logischen Kombination gewünschter
Fähigkeiten
oder anderer Kriterien zu reagieren. Indem das Verzeichnis in einer
hierarchischen oder anderen Topologie organisiert wird, können Nachschlageprotokolle
eine Skalierbarkeit über
eine große
Bandbreite von Netzwerkgrößen liefern.
Als extremes Beispiel ist der Domain Name Service (DNS) des Internets
ein Nachschlagesystem, das als Hierarchie von Servern organisiert
ist, die auf den Maßstab
des Internets als Ganzes anwachsen. Jedoch unterstützen derartige
Protokolle nicht die spontane Hinzufügung oder das spontane Entfernen
von Entitäten
zu und von dem Netzwerk und sind entsprechend auch nicht für „Ad-hoc"-Netzwerke geeignet.
-
Um
diese Unzulänglichkeiten
anzugehen, wurden Entdeckungsprotokolle ersonnen. Bei einem Entdeckungsprotokoll
wirbt eine Entität
für ihre
Fähigkeiten,
z. B. mittels eines Sammelsendens über ein Netzwerk, und die Fähigkeiten
werden durch andere Entitäten
im Cache abgespeichert oder auf andere Weise festgehalten. Wenn
ein Client eine bestimmte Funktion oder Ressource benötigt, kann
er unter Verwendung der im Cache abgespeicherten Informationen eine
Anfrage direkt an den Dienst senden. Ein Client kann auch für eine Anfrage,
die benötigte
Fähigkeiten
darlegt, werben, und ein Dienst, der mit diesen Fähigkeiten übereinstimmt, kann
auf die Anfrage antworten. Als solches ist kein separates Verzeichnis
und kein separater Vermittler erforderlich, und ein derartiges Protokoll
ist rechentechnisch unaufwendig und spricht auf Veränderungen
in dem Netzwerk an.
-
Ein
Beispiel eines Entdeckungsprotokolls ist das Einfacher-Dienst-Entdeckungsprotokoll
(SSDP – simple
service discovery protocol), das in das Universal-Plug-and-Play-Protokoll
(UPnP) von Microsoft integriert wurde. Bei SSDP führen Dienste
ein Sammelsenden ihrer Fähigkeiten über einen
zugewiesenen SSDP-Sammelsendekanal bzw. ein zugewiesenes SSDP-Sammelsendetor
unter Verwendung des HTTP-UDP-Protokolls
durch. Dienste werden unter Verwendung eines Universalressourcenidentifizierers
(URI – universal
resource identifier), der den Dienst und seine Fähigkeiten identifiziert, und
eines eindeutigen Dienstnamens (USN – unique service name) identifiziert.
Der USN ist ein eindeutiger Identifizierer, z. B. ein universeller
eindeutiger Identifizierer (UUID – universal unique identifier).
SSDP verwendet beide oben beschriebenen Entdeckungsverfahren. Wenn
ein Dienst zum ersten Mal mit dem Netzwerk verbunden wird, kündigt er
seine Fähigkeit
und seinen USN an, die eventuell durch zuhörende Entitäten im Cache abgespeichert werden,
während
Clients unter Verwendung eines URI eventuell auch eine Suchanfrage
senden, um den benötigten
Diensttyp zu identifizieren. Obwohl SSDP ein extrem einfaches und
unaufwendiges Protokoll ist, ermöglicht
es den Clients nicht, auf andere Art und Weise als durch Verwendung
der verschiedenen Diensttypidentifizierer zu suchen. Es gibt keine
Entität,
die einem Vermittler entspricht, und das Protokoll führt keinerlei Vermittlung
gemäß der obigen
Definition durch.
-
Ein
ausgefeilteres Protokoll bezüglich
Entdeckung, zusammen mit einer ausgefeilteren Suchfähigkeit und
einer optionalen Verzeichnisfähigkeit
ist „Salutation" (Begrüßung). Bei
dem Salutation-Protokoll sind ein oder mehr Dienste mit einem entsprechenden
Salutation-Verwalter bzw. Begrüßungsverwalter
verbunden. Jeder Begrüßungsverwalter
speichert Informationen über
Dienste, die bei diesem Begrüßungsverwalter
registriert sind. Wenn ein Client einen Dienst ausfindig machen
möchte,
der einen gegebenen Satz von Fähigkeiten aufweist,
damit er eine Anfrage an seinen entsprechenden Begrüßungsmanager,
der andere Begrüßungsmanager
kontaktiert, um Dienste zu identifizieren, die bei diesen Verwaltern
angefordert werden und die benötigte Fähigkeit
aufweisen. Wenn ein Dienst, der die benötigte Fähigkeit aufweist, gefunden
wird, richtet der oder jeder Begrüßungsverwalter anschließend eine
Dienstsitzung ein, um den Client und den Dienst zu verbinden. Es
ist beabsichtigt, dass die Begrüßungsverwalter
unabhängig
von bestimmten Netzwerkprotokollen sind, und Kommunikationen zwischen
Begrüßungsverwaltern über ein
Netzwerk hinweg werden durch eine netzwerkspezifische Transportverwaltungsschicht
gehandhabt. Wie in der Begrüßungs-Architekturspezifikation
festgelegt ist, kann ein Begrüßungsverwalter
Informationen über
bei anderen Begrüßungsverwaltern
registrierte Dienste speichern, um dem Begrüßungsverwalter zu ermöglichen,
ein Verzeichnis von Diensten zu unterhalten, die wichtig für lokale
Dienste oder Clients sind. Es wird sogar in Betracht gezogen, dass
ein Begrüßungsverwalter
in dem Netzwerk als Verzeichnis benannt werden kann, das dafür verantwortlich
ist, alle kompatiblen Dienste zu finden und zu registrieren, und
alle Clientanfragen wurden an diesen Begrüßungsverwalter geleitet, der
als Vermittler agieren würde.
-
Ferner
ist eine auf Java beruhende Lösung,
JINI, bekannt, die eine Kombination von Nachschlage- und Entdeckungstechniken
ist. Auf eine Verbindung mit dem Netzwerk hin macht ein Dienst einen
Nachschlagedienst ausfindig. Nachdem der Dienst den Nachschlagedienst
identifiziert hat, registriert er seine Fähigkeiten bei dem Nachschlagedienst.
Ein Client, der einen geeigneten Dienst identifizieren möchte, sendet
eine Anfrage an den Nachschlagedienst.
-
Das
Dokument WO 0186419 offenbart die Registrierung von JINI-Diensten
und ein System zum Bereitstellen dieser Dienste in einer XML-Umgebung,
indem eine Hin- und Her-Umwandlung
zwischen JINI und XML durchgeführt
wird.
-
Ein
Problem bei jeder oben beschriebenen Technik besteht darin, dass
die Beschreibung jedes Dienstes im Wesentlichen statisch ist. Die über jeden
Dienst verfügbaren
Informationen, ob sie durch einen Vermittler gehalten oder durch
den Dienst beworben werden, berücksichtigen
selbst keine anderen in dem Netzwerk verfügbaren Dienste. Wenn ein Client
eine Funktion ausführen
möchte,
die eine Anzahl von Ressourcen verwendet, die durch getrennte Dienste
bereitgestellt werden, muss der Client diese Dienste getrennt entdecken oder
nachschlagen und sie getrennt aufrufen.
-
Ein
Ziel der Erfindung besteht darin, ein neues oder verbessertes, unaufwendiges
Verfahren zum Vermitteln von über
ein Netzwerk bereitgestellten Diensten zu schaffen.
-
Zusammenfassung
der Erfindung
-
Gemäß einem
ersten Aspekt der Erfindung schaffen wir ein Verfahren zum Vermitteln
von Netzwerkdiensten durch Identifizieren eines Dienstes, der zu
einem Erstdienst komplementär
ist, wobei der Erstdienst eine zugeordnete Erstdienstbeschreibung
aufweist, die Erstdienstidentifizierungsinformationen, die den angebotenen
Dienst identifizieren, und Erstschnittstellentypinformationen umfasst,
wobei die Erstschnittstellentypinformationen zumindest entweder
ein durch den Erstdienst akzeptiertes Eingabeformat und/oder ein
durch den Erstdienst erzeugtes Ausgabeformat umfassen, wobei das
Verfahren folgende Schritte umfasst: Identifizie ren eines Zweitdienstes,
der eine zugeordnete Zweitdienstbeschreibung aufweist, die Zweitdienstidentifizierungsinformationen,
die den angebotenen Dienst identifizieren, und Zweitschnittstellentypinformationen
umfasst, die zu den Erstschnittstellentypinformationen komplementär sind,
und Modifizieren der Erstdienstbeschreibung gemäß der Zweitdienstbeschreibung.
-
Manche
oder alle Dienste in einem Netzwerk sind in der Lage, komplementäre Dienste
zu identifizieren und ihre eigene Beschreibung gemäß einem
identifizierten komplementären
Dienst zu modifizieren und dadurch in der Tat den identifizierten
Dienst zu vermitteln. Um beide Dienste aufzurufen, muss der Client
lediglich eine einzige Anfrage an den ersten Dienst senden.
-
Der
Schritt des Identifizierens eines Zweitdienstes kann ein Vergleichen
der Erstschnittstellentypinformationen und der Zweitschnittstellentypinformationen
umfassen, wobei der Erstdienst und der Zweitdienst komplementär sind,
wenn ein durch den Erstdienst akzeptiertes Eingabeformat mit einem
durch den Zweitdienst erzeugten Ausgabeformat übereinstimmt oder wenn ein
durch den Zweitdienst akzeptiertes Eingabeformat mit einem durch
den Erstdienst erzeugten Ausgabeformat übereinstimmt.
-
Wenn
ein durch den Erstdienst akzeptiertes Eingabeformat mit einem durch
den Zweitdienst erzeugten Ausgabeformat übereinstimmt, umfasst der Schritt
des Modifizierens der Erstdienstbeschreibung ein Hinzufügen eines
durch den Zweitdienst akzeptierten Eingabeformats zu den Erstschnittstellentypinformationen.
-
Wenn
ein durch den Zweitdienst akzeptiertes Eingabeformat mit einem durch
den Erstdienst erzeugten Ausgabeformat übereinstimmt, umfasst der Schritt
des Modifizierens der Erstdienstbeschreibung ein Hinzufügen eines
durch den Zweitdienst erzeugten Ausgabeformats zu den Erstschnittstellentypinformationen.
-
Der
Schritt des Modifizierens der Erstschnittstellentypinformationen
kann ein Hinzufügen
von Gewichtsinformationen umfassen, die angeben, dass ein Eingabeformat
oder Ausgabeformat einem Zweitdienst entspricht.
-
Der
Schritt des Modifizierens der Erstdienstbeschreibung kann ein Erzeugen
einer Komplementärdiensttabelle
umfassen, die den Zweitdienst und die Schnittstellentypinformationen,
die diesem Dienst entsprechen, identifiziert.
-
Der
Schritt des Modifizierens der Erstdienstbeschreibung kann ein Modifizieren
der Erstdienstidentifizierungsinformationen gemäß den Zweitdienstidentifizierungsinformationen
umfassen.
-
Der
Schritt des Identifizierens eines Zweitdienstes kann ein Empfangen
der Zweitdienstbeschreibung über
ein Netzwerk umfassen.
-
Der
Schritt des Zurverfügungstellens
der Erstdienstbeschreibung über
ein Netzwerk.
-
Der
Schritt des Empfangens einer Dienstanforderung von einem Client
an dem Erstdienst, des Vergleichens der Clientanforderung mit den
Erstschnittstelleninformationen und des Aufrufens des Zweitdienstes.
-
Der
Schritt des Sendens der Clientanforderung von dem Erstdienst an
den Zweitdienst, des Empfangens einer Antwort von dem Zweitdienst
und des Aufrufens des Erstdienstes gemäß der Antwort.
-
Der
Schritt des Aufrufens des Erstdienstes gemäß der Clientanforderung, des
Erzeugens einer Ausgabe und des Sendens der Ausgabe an den Zweitdienst.
-
Gemäß einem
zweiten Aspekt der Erfindung liefern wir einen Vermittler zum Vermitteln
von Netzwerkdiensten, wobei dem Vermittler ein in dem Netzwerk vorgesehener
Erstdienst zugeordnet ist, wobei der Vermittler eine Erstdienstbeschreibung
aufweist, die Erstdienstidentifizierungsinformationen, die den angebotenen
Dienst identifizieren, und Erstschnittstellentypinformationen umfasst,
wobei die Erstschnittstellentypinformationen zumindest entweder
ein durch den Erstdienst akzeptiertes Eingabeformat und/oder ein
durch den Erstdienst erzeugtes Ausgabeformat umfassen, wobei der
Vermittler wirksam ist, um einen Zweitdienst zu identifizieren,
der eine zugeordnete Zweitdienstbeschreibung aufweist, die Zweitdienstidentifizierungsinformationen,
die den angebotenen Dienst identifizieren, und Zweitschnittstellentypinformationen
umfasst, die zu den Erstschnittstellentypinformationen komplementär sind,
und die Erstdienstbeschreibung gemäß der Zweitdienstbeschreibung
zu modifizieren.
-
Kurze Beschreibung
der Figuren
-
Unter
Bezugnahme auf die beiliegenden Zeichnungen wird nun beispielhaft
ein Ausführungsbeispiel der
vorliegenden Erfindung beschrieben. Es zeigen:
-
1 eine
schematische Veranschaulichung eines Netzwerks, das Dienste umfasst,
die die vorliegende Erfindung verkörpern;
-
2 eine
schematische Veranschaulichung von komplementären und nicht-komplementären Diensten;
-
3a eine
Veranschaulichung eines Verfahrens, das die vorliegende Erfindung
verkörpert;
-
3b eine
Veranschaulichung eines Verfahrens, das die vorliegende Erfindung
verkörpert
und auf die Schritte der 3a folgt;
-
4a eine
Veranschaulichung eines weiteren Verfahrens, das die vorliegende
Erfindung verkörpert; und
-
4b eine
Veranschaulichung eines weiteren Verfahrens, das die vorliegende
Erfindung verkörpert und
auf den Schritt der 4b folgt.
-
Beschreibung
der bevorzugten Ausführungsbeispiele
-
Unter
Bezugnahme auf 1 ist ein Netzwerk 10 gezeigt,
mit dem vier Entitäten 11, 12, 13, 14 verbunden
sind. Bei diesem Beispiel ist die Entität 11 eine physische
Vorrichtung, die einen Drucker umfasst, Entitäten 12 und 13 sind
Anwendungen, bei diesem Beispiel Dateiübersetzer, und die Entität 14 ist
ein Personal-Computer. Der Drucker 11 und der Übersetzer
bzw. die Übersetzungseinrichtung 12 sind
mit einem Vermittler 15 bzw. 16 gemäß der vorliegenden
Erfindung ausgestattet. Jeder Vermittler 15, 16 umfasst
eine Dienstbeschreibung 15a, 16b und eine Komplementärdienstliste 15b, 16b.
Die Entität 13 ist
mit einer Dienstbeschreibung 17 ausgestattet, da der Übersetzer 13 einen über das
Netzwerk 10 zugänglichen
Dienst liefert, jedoch keinen Vermittler aufweist. Der PC 14 liefert
keinen Dienst und weist somit auch keine Dienstbeschreibung auf.
-
Die
Dienstbeschreibung 15a, 16a umfasst Dienstidentifizierungsinformationen,
die angeben, welcher Dienst durch die Entität bereitgestellt wird, und
Schnittstelleninformationen, die das Eingabeformat oder Daten eines
Dateityps, das bzw. der durch den Dienst akzeptiert werden, und/oder
das durch den Dienst erzeugte Ausgabeformat darlegen. Die Dienstbeschreibung 15a, 16a umfasst
ferner eine Angabe der Lokalität
des Dienstes. Die Komplementärdienstliste 15b, 16b umfasst
eine Tabelle, die ein Eingabe- oder Ausgabeformat, den entsprechenden
verwendeten Dienst und eine Örtlichkeit
für diesen
Dienst darlegt.
-
Bei
dem vorliegenden Beispiel spricht man davon, dass zwischen zwei
Diensten A und B eine komplementäre
Beziehung vorliegt, wenn das Ausgabeformat von A mit dem Eingabeformat
von B übereinstimmt. Man
spricht davon, dass die Dienste A und B komplementäre Dienste
sind. Somit ist bei dem Beispiel der 2a ein
PostScript-zu-PCL-Übersetzer
mit einem Eingabeformat mime-Typ-PostScript und Ausgabeformat mime-Typ-PCL
komplementär
zu einem Drucker, der PCL mit einem Eingabeformat mime-Typ-PCL unterstützt. Ein
MPEG-Darstellungsprogrammdienst
mit einem Eingabeformat mime-Typ-MPEG
und ohne Ausgabe steht nicht in einer komplementären Beziehung zu einem Drucker,
der PCL mit einem Eingabeformat mime-Typ-PCL und ohne Ausgabe unterstützt.
-
Um
ein unaufwendiges Vermitteln zu liefern, indem eine Gemeinschaft
von komplementären
Vorrichtungen eingerichtet wird, modifiziert der Vermittler 15, 16 die
Dienstbeschreibung 15a, 16a und die Komplementärdienstliste 15b, 16b ansprechend
auf das Vorliegen von komplementären
Diensten, die mit dem Netzwerk 10 verbunden sind.
-
Unter
Bezugnahme auf 3 wird nun das Verfahren
des Vermittelns von Diensten in dem Netzwerk 10 beschrieben.
-
Zuerst
muss sich jeder Vermittler 15 Diensten, die durch andere
mit dem Netzwerk 10 verbundene Entitäten bereitgestellt werden,
gewahr sein. Gemäß der SSDP-Spezifikation
sendet beispielsweise jede Entität daraufhin,
dass sie mit dem Netzwerk 10 verbunden wird, über einen
festgelegten Sammelsendekanal oder ein festgelegtes Sammelsendetor
eine Vorhandensein-Ankündigung.
Die Vorhandensein-Ankündigung
umfasst einen eindeutigen Dienstidentifizierer, beispielsweise einen
universell eindeutigen Identifizierer (UUID), Informationen, die
der Dienstbeschreibung, die den Dienst festlegt, entsprechen, Schnittstelleninformationen und
eine Örtlichkeit
dieses Dienstes. Das Sammelsenden wird von alle Entitäten empfangen,
die an das Netzwerk 10 angeschlossen sind und in der Lage
sind, Nachrichten auf dem Sammelsendekanal zu empfangen.
-
Auf
einen Empfang der Vorhandensein-Ankündigung hin vergleicht der
Vermittler
15,
16 die in der Vorhandensein-Ankündigung
empfangenen Schnittstellentypinformationen mit den Schnittstelleninformationen
in der Dienstbeschreibung
15a,
16a. Wenn die in
der Vorhandensein-Ankündigung
enthaltenen Schnittstellentypinformationen angeben, dass der die
Ankündigung
durchführende
Dienst ein komplementärer
Dienst ist, fügt der
Vermittler
15,
16 den Dienst zu seiner zugeordneten
Komplementärdienstliste
hinzu und modifiziert seine Schnittstelleninformationen, so dass
sie mit denjenigen, die in der Vorhandensein-Ankündigung empfangen wurden, übereinstimmen.
Beispielsweise im Netzwerk der
1 kann der
Drucker
11 eine Dienstbeschreibung aufweisen, die wie folgt
lautet:
| Dienstidentifizierungsinformationen: | Drucker,
der PCL unterstützt |
| Schnittstelleninformationen: | eingegeben:
mime-Typ-PCL
ausgegeben:
keines |
-
Wie
in
3a gezeigt ist, vergleicht der Vermittler
15 auf
einen Empfang einer Vorhandensein-Ankündigung von dem Übersetzer
12,
die die Dienstbeschreibungsinformationen
16a umfasst, die
Schnittstelleninformationen in der Dienstbeschreibung
15a.
Die Dienstbeschreibung
15a gibt an, dass die Ausgabe des Übersetzers
12 PCL
ist, was mit dem Eingabetyp des Druckers
11 übereinstimmt,
und somit sind der Drucker
11 und der Übersetzer
12 komplementär. Wie in
3b gezeigt
ist, modifiziert der Vermittler
15 die Dienstbeschreibung
15a so,
dass sie sich folgendermaßen
liest:
| Dienstidentifizierungsinformationen: | Drucker,
der PCL unterstützt |
| Schnittstelleninformationen: | eingegeben:
mime-Typ-PCL
eingegeben:
mime-Typ-PostScript
ausgegeben:
keines |
-
Das
bedeutet, dass der Vermittler 15 den Eingabeformattyp des Übersetzers 12 zu
den Schnittstelleninformationen in der Dienstbeschreibung 15a hinzugefügt hat.
Es kann auch in Betracht gezogen werden, dass der Vermittler 15 den
Dienstbeschreibungstyp beispielsweise zu „Drucker, der PCL und PostScript
unterstützt" ändern könnte. Der Vermittler 15 empfängt die
Dienstbeschreibung 17 von dem Übersetzer 13, da jedoch
der Drucker 11 und der Übersetzer 13 insofern
nicht komplementär
sind, als keine übereinstimmenden Eingabe-
und Ausgabeformate vorliegen, modifiziert der Vermittler 15 weder
die Dienstbeschreibung 15a, noch ändert er die Komplementärdienstliste 15b.
-
Wie
in 3a gezeigt ist, führt der Vermittler 16 dieselbe
Analyse durch und identifiziert den Übersetzer 13 insofern
als zu dem Übersetzer 12 komplementären Dienst,
als der Ausgabetyp des Übersetzers 13 mit dem
Eingabeformattyp des Übersetzers 12 übereinstimmt.
Der Vermittler 16 modifiziert die Dienstbeschreibung 16a auf ähnliche
Weise, wie sie oben bei 3b beschrieben
wurde, so dass sie das Eingabeformat-GIF in den Schnittstelleninformationen
für den Übersetzer 12 enthält, und
er modifiziert die Komplementärdienstaufzeichnungen 16b so,
dass sie den Übersetzer 13 identifizieren.
-
Wenn
also ein Clientsystem, beispielsweise der Personal-Computer 14,
ein Dokument in einem PostScript-Format drucken möchte, kann
der Personal-Computer 14 eine entspre chende Entdeckungsanfrage senden,
die festlegt, dass er einen Drucker benötigt, der in der Lage ist,
PostScript-Dokumente
zu drucken. Die Entdeckung kann auf jegliche beliebige Weise durchgeführt werden,
beispielsweise kann eine Entdeckungsanfrage als SSDP-Sammelsendung über das
Netzwerk 10 gesendet werden, oder der Drucker 11 kann über den
Sammelsendekanal seine revidierte Dienstbeschreibung ankündigen,
die gemäß der SSDP-Spezifikation
durch den Personal-Computer 14 empfangen und im Cache abgespeichert
wird. Der Personal-Computer 14 sendet das PostScript-Dokument an den Drucker 11.
Der Vermittler 15 empfängt
das PostScript-Dokument, sendet es über das Netzwerk 10 an
den Übersetzer 12 und
empfängt
von dem Übersetzer 12 das übersetzte
Dokument im PCL-Format, das anschließend durch den Drucker 11 gedruckt
wird.
-
Auf
diese Weise wurde ein Vermittlungsvorgang durchgeführt, der
für das
Clientsystem, den Personal-Computer 14, transparent ist.
So weit sich das Clientsystem 14 gewahr ist, hat es einfach
ein PostScript-Dokument an einen zu PostScript fähigen Drucker gesendet. Es
wurde keine Verwaltung oder manuelle Installation benötigt, da
der Vermittler 15 einen komplementären Dienst automatisch erfasst
hat, die Dienstbeschreibung 15a des Druckers 11 modifiziert
und den Übersetzungsdienst 12 aufgerufen
hat. Der Dienst kann mittels eines beliebigen geeigneten Verfahrens
aufgerufen werden, beispielsweise unter Verwendung des einfachen
Objektzugriffsprotokolls (SOAP – Simple
Object Access Protocol).
-
Wie
oben beschrieben wurde, suchten. die Vermittler 15 und 16 insofern
nach „rückwärts" komplementären Beziehungen,
als sie Dienste identifizieren, die ein Ausgabeformat aufweisen,
das mit dem Eingabeformat des zugeordneten Dienstes des Vermittlers übereinstimmt.
Es wird einleuchten, dass komplementäre Beziehungen als vorwärts komplementär ausgewählt werden
könnten,
d. h. dass der Vermittler Dienste identifiziert, die ein Eingabeformat
aufweisen, das mit dem Ausgabeformat des zugeordneten Dienstes des
Vermittlers übereinstimmt.
Bei diesem Beispiel modifiziert der Vermittler 16 die Dienstbeschreibung 16a und
Komplementärdienstaufzeichnungen 16b des Übersetzers 12 so,
dass sie die Fähigkeiten
des Druckers 11 umfassen. Es wäre sogar möglich, sowohl nach vorwärts als
auch nach rückwärts komplementären Beziehungen
zu suchen, dies wiese jedoch ein sich daraus ergebendes Risiko einer
Vervielfältigung
komplementärer
Dienste auf, d. h. der Vermittler 15a würde die Dienstbeschreibung 15a und
die Komplementärdienstaufzeichnung 15b so modifizieren,
dass sie die Fähigkeiten
des Übersetzers 12 berücksichtigen,
und der Vermittler 16 würde
die Dienstbeschreibung 16a und die Komplementärdienstaufzeichnung 16b so
modifizieren, dass sie den Drucker 11 berücksichtigen.
Beide Dienstbeschreibungen 15, 16 würden dann
einen Drucker anzubieten scheinen, der PostScript-Dateien annimmt.
-
Ferner
könnte
in Betracht gezogen werden, dass der Prozess des Identifizierens
von komplementären Diensten
wiederholt wird, beispielsweise dass zwei oder mehr Identifizierungsschritte
durchgeführt
werden. Wie oben unter Bezugnahme auf 3b erörtert wurde,
hat der Vermittler 15 die Dienstbeschreibung 15a so abgeändert, dass
sie festlegt, dass der Drucker 11 ein Eingabeformat mime-Typ-PostScript
akzeptiert, und hat der Vermittler 16 die Dienstbeschreibung 16a dahingehend
modifiziert, hinzuzufügen,
dass der Übersetzer 12 das
Eingabeformat mime-Typ-GIF-Dateien akzeptiert. Wie in 4a gezeigt
ist, würde
der Vermittler 15, wenn er erneut nach „rückwärts" komplementären Diensten sucht, identifizieren,
dass der Übersetzer 13 nun
ein zu dem Drucker 11 komplementärer Dienst ist, da der Drucker 11 nun
PostScript-Dateien akzeptiert und der Übersetzer 13 PostScript-Dateien
ausgibt. Der Vermittler 15 modifiziert die Dienstbeschreibung 15a und
die Komplementärdienstaufzeichnung 15b wie
oben beschrieben, so dass sie das Eingabeformat mime-Typ-GIF umfassen,
wie in 4b gezeigt ist.
-
Wenn
mehrere derartige Schritte zum Identifizieren komplementärer Dienste
durchgeführt
werden, könnte
dies potentiell zu einer sehr großen Anzahl möglicher
Kombinationen von komplementären
Diensten führen,
und somit werden mehrere Schritte umfassende Suchvorgänge vorzugsweise
durch entsprechende Regeln eingeschränkt. Beispielsweise sucht ein
Vermittler eventuell nicht nach komplementären Diensten, die mit einem
in seinen Schnittstelleninformationen aufgeführten bestimmten Eingabetyp übereinstimmen,
wenn dieser Eingabetyp selbst vermittelt wird. Bei dem obigen Beispiel
sucht der Vermittler 15 nicht nach Diensten, die ein Ausgabeformat
mime-Typ-PostScript aufweisen, da diese Eingabe vermittelt wird,
d. h. durch einen komplementären
Dienst, den Übersetzer 12,
bereitgestellt wird. Wenn der Vermittler 16 den Übersetzer 13 jedoch
als einen zu dem Übersetzer 12 komplementären Dienst
identifiziert hat und die Eingabeformate mime-Typ-GIF und mime-Typ-PostScript
anbietet, liest der Vermittler 15 eventuell die Dienstbeschreibung 16a und
fügt mime-Typ-GIF
und mime-Typ-PostScript
eventuell zu seiner Dienstbeschreibung 15a hinzu. Auf diese Weise
werden die komplementären
Dienste eingerichtet, so dass der Drucker in der Lage ist, aus jedem
der verfügbaren
Dateitypen zu drucken, ohne dass jedoch eine Vervielfältigung
vermittelter Dienste vorliegt.
-
Ein
weiteres Verfahren zum Steuern der Anzahl vermittelter Dienste kann
darin bestehen, die durch einen Dienst angebotenen Eingabeformate,
die vermittelt werden, zu etikettieren oder, in diesem Beispiel,
zu gewichten. Somit könnte
der Drucker bei dem mehrere Schritte umfassenden Beispiel Eingabeformate
mime-Typ-PostScript und mime-Typ-GIF etikettieren, um zu zeigen,
dass diese Fähigkeiten
durch einen vermittelten komplementären Dienst angeboten werden.
Ein Client 14 wäre
sich dann gewahr, dass der komplementäre Dienst eventuell nicht verfügbar ist,
beispielsweise im Fall eines Ausfalls des Übersetzers 12, dessen
sich der Drucker 11 nicht gewahr ist. Wie oben erörtert wurde,
ist ein Vermittler beim Durchführen
mehrerer Durchläufe,
um komplementäre
Dienste zu identifizieren, eventuell eingestellt, nicht nach vermittelten
Eingabetypen zu suchen.
-
Statt
eines einfachen Etikettierens können
an Eingabetypen Gewichte befestigt werden, wie in 4 bei 19 gezeigt
ist. Das Gewichten würde
den Umfang, in dem ein Dienst vermittelt wird, z. B. die Anzahl
von Diensten, die erforderlich sind, um die angebotene Fähigkeit
oder Funktion bereitzustellen, angeben. Wie in 4 gezeigt
ist, gibt die Dienstbeschreibung 15a an, dass der Drucker 11 eingegebenes
mime-Typ-PCL mit Gewicht 1, eingegebenes mime-Typ-PostScript mit Gewicht
2 und eingegebenes mime-Typ-GIF mit Gewicht 3 akzeptiert. Das Gewicht 19 gibt
die Anzahl von Diensten an, die verwendet werden, um eine Funktion
durchzuführen,
z. B. werden drei Entitäten,
die Übersetzer 12 und 13 und
der Drucker 11, benötigt,
um die Funktion des Druckens von GIF-Dokumenten durchzuführen. Der
Vermittler 15 kann dieses Gewicht anschließend dazu verwenden,
die effizienteste Weise des Bereitstellens einer Funktion zu bewerten.
Wenn beispielsweise ein weiterer Server, der einen GIF-zu-PCL-Übersetzer
umfasst, in dem Netzwerk 10 zur Verfügung gestellt werden und sein
Vorhandensein ankündigen
soll, würde
der Vermittler 15a den Dienst als komplementären Dienst
erfassen und eine Eingabe von mime-Typ-GIF mit Gewicht 2 zu der
Dienstbeschreibung 15a hinzufügen. Die Eingang von mime-Typ-GIF
mit Gewicht 3 könnte
anschließend
aus der Dienstbeschreibung 15a und der Komplementärdienstliste 15b entfernt
werden. Alternativ dazu könnte
der Vermittler 15 das Eingabeformat mime-Typ-GIF mit Gewicht
3 beibehalten und auf einen Empfang einer GIF-Datei hin versuchen,
Dienste, die eine GIF-Übersetzung
anbieten, in einer aufsteigenden Reihenfolge des Gewichts aufzurufen.
-
Ein
Vermittler kann eine festgelegte Gewichtsgrenze aufweisen, die beispielsweise
lautet, dass nur Schnittstellentypen mit einem Gewicht von 3 oder
weniger angeboten werden sollten.
-
Desgleichen
können
einem Client 14 eine Anzahl von Diensten angeboten werden,
die eine gewünschte
Fähigkeit
aufweisen, und der Client 14 kann vorzugsweise diejenigen
Dienste aufrufen, die das geringste Gewicht aufweisen.
-
Eine
weitere Technik zum Steuern der Anzahl komplementärer Dienste
beim Durchführen
einer aus mehreren Schritten bestehenden Suche besteht darin, zu
der Dienstbeschreibung 15a, 16a, 17a ein
Flag hinzuzufügen,
das festlegt, ob die entsprechende Entität 11, 12, 13 einen
Vermittler umfasst oder nicht und ein komplementäres Vermitteln unterstützt oder
nicht. Der Vermittler 15, 16 kann dann eingestellt
werden, nur dann nach Diensten, die zu einem vermittelten Schnittstellendienst
komplementär
sind, zu suchen, wenn der Dienst, der diesen Schnittstellentyp bereitstellt,
nicht selbst ein Vermitteln unterstützt.
-
Bei
dem Beispiel der 4a sucht der Drucker 15 nach
Diensten, die in einer komplementären Beziehung zu dem vermittelten
eingegebenen mime-Typ-PostScript stehen. Wenn die Dienstbeschreibung 16a so etikettiert
werden soll, dass sie zeigt, dass der Vermittler 16 ein
komplementäres
Vermitteln unterstützt,
würde der
Vermittler 15 nicht nach Diensten mit einer Ausgabe mime-Typ-PostScript
suchen. Stattdessen würde
der Vermittler 16 des Übersetzers 12 den Übersetzer 13 als
komplementären
Dienst erfassen, wie in 3 gezeigt ist,
und die Dienstbeschreibung 16a entsprechend abändern. Der
Vermittler 15 würde
die Dienstbeschreibung 15a dann dahingehend abändern, dass
sie die revidierte Dienstbeschreibung 16a berücksichtigt.
Die Dienstbeschreibung 15a würde immer noch dieselbe Liste
von Gewichtseingabetypen aufweisen, die in 4b gezeigt
sind, jedoch würde
die Vervielfachung der Arbeit, die ins Spiel kommt, wenn sowohl
der Vermittler 15 als auch der Vermittler 16 nach
Diensten suchen, die zu dem Eingabeformat mime-Typ-PostScript komplementär sind,
vermieden werden.
-
Um
zu ermöglichen,
dass eine aus mehreren Schritten bestehende Suche komplementäre Dienste identifiziert,
ist es notwendig, dass jeder Dienst seine revidierte Dienstbeschreibung
in dem Netzwerk 10 zur Verfügung stellt. Bei dem in dieser
Beschreibung von SSDP verwendeten Beispiel ist nicht vorgesehen,
dass eine Vorrichtung eine Sammelsende-Ankündigung
ihrer Verfügbarkeit
macht, es sei denn, sie ist zum ersten Mal in dem Netzwerk verfügbar. Es
könnte
jedoch in Betracht gezogen werden, dass, wenn eine Vorrichtung ihre
Dienstbeschreibung 15a dahingehend abändert, einen neuen Schnittstellentyp
hinzuzufügen,
der Dienst eine Sammelsendung über
das Netzwerk 10 macht, die seine revidierte Dienstbeschreibung
ankündigt,
und dass ein Vermittler in dem Netzwerk 10 dann die revidierte
Dienstbeschreibung erfassen und entsprechend agieren kann, wie oben
dargelegt wurde. Alternativ oder zusätzlich dazu kann, wenn ein
Vermittler eine Dienstbeschreibung dahingehend abändert, einen
neuen Schnittstellentyp hinzuzufügen,
der Dienst eine Anfrage über
das Netzwerk 10 senden, um Dienste zu identifizieren, die
zu dem neuen Eingabeformat- oder Ausgabeformattyp komplementär sind,
und dementsprechend eine Komplementärvorrichtungsliste erstellen.
Der Schritt des Sendens einer Sammelsende-Anfrage, um einen Dienst
mit einer bestimmten Fähigkeit
zu identifizieren, entspricht der SSDP-Spezifikation.
-
Bei
dem SSDP sendet eine Entität,
die gerade aus dem Netzwerk entfernt wird, eine Sammelsende-Ankündigung,
dass sie nicht mehr zur Verfügung
stehen wird. Vermittler 15, 16 können eine
derartige Sammelsendung empfangen. und die Dienstbeschreibung 15a, 16a und
die Komplementärdienstliste 15b, 16b so abändern, dass
dieselben eine derartige Sammelsendung berücksichtigen, wobei der Dienst
aus der Komplementärdienstliste 15b, 16b gelöscht wird
und Eingabetypen oder Ausgabetypen, die durch diesen Dienst vermittelt
wurden, aus der Dienstbeschreibung 15a, 16a entfernt
werden.
-
Obwohl
das vorliegende Beispiel in Bezug auf SSDP erörtert wurde, wird einleuchten,
dass dieses mit geringem Aufwand verbundene Vermittlungsverfahren
nach Wunsch mit jedem beliebigen geeigneten Entdeckungssystem verwendet
werden kann. Es kann in Betracht gezogen werden, dass die Technik
bei einem Vermittlungssystem verwendet wird, das ein Verzeichnis
verwendet, wobei ein einem Dienst zugeordneter Vermittler in der
Lage ist, das Verzeichnis zu befragen, um komplementäre Dienste
zu identifizieren. Obwohl bei dem vorliegenden Beispiel jedem Dienst
ein Vermittler zugeordnet ist, kann in Betracht gezogen werden,
dass eventuell ein selbständiger
Vermittler verwendet wird, der eine Komplementärdienstliste zusammenstellt.
Der selbständige
Vermittler würde
dann in dem Netzwerk auf transparente Weise als ein oder mehr Dienste
erscheinen und kann durch einen Client 14 adressiert werden,
als ob er ein Dienst wäre.
-
Es
wird einleuchten, dass ein derartiges Vermitteln nach Wunsch bei
jeglichem Netzwerktransportprotokoll verwendet werden kann.
-
Das
hierin beschriebene Verfahren zum Vermitteln komplementärer Dienste
weist somit die Vorteile auf, dass es insofern rechentechnisch unaufwendig
ist, als jeder Vermittler selbst ein relativ einfaches Programm
oder ein anderes Softwareelement sein kann. Es wird keine Verwaltung
der Vermittlung benötigt,
da die Identifizierung und das Anbieten von komplementären Diensten
ansprechend auf Dienste, die ihr Vorhandensein und ihre Fähigkeit
in dem Netzwerk bewerben, automatisch durchgeführt wird. Das Verfahren ist
insofern robust, als einzelne Vermittler über eine Anzahl von Entitäten in einem
Netzwerk verteilt sind und das Entfernen oder Hinzufügen eines
Vermittlers und/oder eines Dienstes automatisch bewerkstelligt wird.
-
In
der vorliegenden Spezifikation bedeutet „umfasst" „beinhaltet
oder besteht aus",
und „umfassen" bedeutet „beinhalten
oder bestehen aus".