-
ALLGEMEINER
STAND DER TECHNIK
-
Die
vorliegende Erfindung betrifft ein Verfahren zum Bereitstellen von
Diensten von Diensteanbieterhosts an Diensteteilnehmerhosts in einem Kommunikationsnetzwerk
und konkret, wenn die Diensteteilnehmerhosts versuchen, aus eigenem
Antrieb verfügbare
Dienste in dem Kommunikationsnetzwerk aufzufinden.
-
Ein
Diensteteilnehmerhost ist im Zusammenhang mit dieser Erfindung als
ein Host des Kommunikationsnetzwerkes zu verstehen, welcher von
einem in dem Kommunikationsnetzwerk vorhandenen Diensteanbieterhost
einen Dienst geliefert haben will. Für diesen Zweck kann der Diensteteilnehmerhost
eine Liste von Diensten herunterladen und einen Dienst aus dieser
Liste auswählen.
Im Anschluß wird
eine Transaktion zwischen dem Diensteteilnehmerhost und dem Diensteanbieterhost
gestartet. Diese Transaktion läuft
gewöhnlich
nach dem Client-Server-Modell
ab.
-
Ein
Nachteil ist, daß die
Diensteteilnehmerhosts mit einer Liste von Diensten versehen sind,
die möglicherweise
sehr viele Dienste enthält,
an denen der Nutzer des Diensteteilnehmerhost nicht interessiert
ist.
-
Überdies
können
speziell im Zusammenhang mit zielgerichteten Kommunikationsnetzwerken solche
Listen nicht ohne weiteres gepflegt werden, da die Topologie und
der Aufbau des zielgerichteten Kommunikationsnetzwerkes oft geändert wird.
Dann muß ein
Diensteteilnehmerhost, statt eine Liste von Diensteanbieterhosts
zu erhalten, in der Lage sein, seine Umgebung selbst zu erkennen.
-
Eine
grundlegende Prozedur zum Auffinden von Diensten (Service Discovery
Protocol) wurde im Rahmen der Bluetooth-Technologie implementiert. Eine solche
Prozedur zum Auffinden von Diensten wurde mit der Einführung der Salutationsprotokolle verbessert,
die speziell vorgesehen sind, um potentiellen Diensteteilnehmerhosts
zu ermöglichen,
entsprechende entfernte Diensteanbieterhosts in ihrer Umgebung über Anfragen
an eine zentrale Dienstedatenbank zu ermitteln. Ein Diensteteilnehmerhost, der
versucht einen vordefinierten Dienst zu erhalten, erzeugt für diesen
Dienst eine Anfrage und nimmt sie in das Salutationsprotokoll auf.
Wenn ein Diensteanbieterhost, der über die Bluetooth-Schnittstelle
erreichbar ist, diesen Dienst unterstützt, antwortet er durch Zurücksenden
seines Identifikators auf die Anfrage. Anschließend kann eine Client-Server-Transaktion
durchgeführt
werden und der Dienst kann auf dem Diensteteilnehmerhost bereitgestellt
werden.
-
Solch
ein Salutationsprotokoll mit Dienstanfrage, wie für Diensteteilnehmerhosts
und Diensteanbieterhosts mit der Bluetooth-Technologie standardisiert,
ist im Dokument "Mapping
salutation architecture APIs to Bluetooth Service Discovery Layer" Version 1.0, 01.
Juli 1999, von der Bluetooth Special Interest Group beschrieben.
-
Diese
Lösung
hat aber den Nachteil, daß sowohl
der Diensteanbieterhost als auch der Diensteteilnehmerhost die gleiche
Sprache zum Unterscheiden des Dienstes, d.h. den gleichen Dienstenamen, die
gleichen Diensteparameter, die gleichen Diensteoptionen, verwenden
müssen.
Dies ist relativ einfach im Rahmen von Bluetooth-fähigen Geräten zu gewährleisten,
welche in der Regel standardisierte Grunddienste bereitstellen.
Im Zusammenhang mit dem zielgerichteten Konfigurationsnetzwerk sind komplexere
Dienste bereitzustellen. Es ist unwahrscheinlich, daß einem
Diensteteilnehmerhost vorab die entsprechenden Variablen bekannt
sind, um den Dient zu parametrisieren. Das Ergebnis einer Dienstanfrage
mit auf einem Diensteteilnehmerhost vermuteten und auf einem Diensteanbieterhost
ausgeführten
Parametern ist sehr schwer zu berechnen.
-
E.
Guttman, "Service
Location Protocol, Version 2",
RFC 2608, und E. Guttman, "Service
Template und Service Scheme",
RFC 2609, offenbaren ein Diensteortsprotokoll, wo ein Nutzer den
gewünschten
Typ der Dienste und einen Satz von Attributen, welche den Dienst
beschreiben, bereitstellt. Auf der Grundlage dieser Beschreibung
löst das
Diensteortsprotokoll die Netzwerkadresse des Dienstes für den Nutzer
auf. Die Dienste werden gemäß den Diensteschablonen
beschrieben. Die Schablonen werden verwendet, um die Diensteregistrierung
bei einem Diensteagenten oder Verzeichnisagenten zu erzeugen, die
für das
Ankündigen
von Diensten verantwortlich sind.
-
Eine
spezielle Aufgabe der vorliegenden Erfindung ist, ein Verfahren
zum Bereitstellen von effizienteren Diensten an Diensteteilnehmerhosts
bereitzustellen, insbesondere im Zusammenhang von zielgerichteten
Netzwerken, so daß die
Diensteanbieterhosts die Dienste von Diensteanbieterhosts präziser anfragen
können.
-
Eine
andere Aufgabe der Erfindung ist, eine Hoststruktur des Diensteteilnehmers
bereitzustellen, um das Verfahren gemäß der vorliegenden Erfindung durchzuführen.
-
KURZDARSTELLUNG
DER ERFINDUNG
-
Diese
Aufgaben und andere, die unten aufgeführt sind, werden durch ein
Verfahren zum Bereitstellen von Diensten in einem Kommunikationsnetzwerk
nach Anspruch 1 und einen entsprechenden Diensteteilnehmerhost nach
Anspruch 6 erreicht.
-
Gemäß der vorliegenden
Erfindung kann ein Diensteteilnehmerhost eine Datenstruktur herunterladen,
die hier als Diensteprofil bezeichnet ist, das dem Typ des von ihm
gewünschten
Dienstes entspricht, und ein Dienstanfragekriterium absetzen, das
aus eingeschränkten
Attributwerten und Eigenschaften dieses Diensteprofils besteht.
Er kann ebenfalls nur nach Diensten nachfragen, die dem Diensteprofil
ohne Einschränkung
entsprechen. Die Dienstanfrage wird an einen Dienstebeschreibungsserver
gesendet, welcher die Dienstebeschreibung enthält, die Konkretisierungen des
Diensteprofils sind, wobei jede zusätzlich einen Identifikator
eines Diensteanbieterhost umfaßt,
der diesen Dienst unterstützt.
Jeder Server, der solch einen "übereinstimmenden" Dienst konkretisiert,
sendet seine Identität und
Dienstenamen zurück.
Abschließend
kann eine Client-Server-Verbindung zwischen dem Diensteteilnehmerhost
und dem Diensteanbieterhost, der den angefragten Dienst unterstützt, aufgebaut
werden, vorausgesetzt, daß der
entsprechende Dienste-Client auf der Benutzerseite vorhanden ist.
-
Das
Verfahren gemäß der vorliegenden
Erfindung hat den Vorteil, daß auf
dem Diensteteilnehmerhost wenig Rechenleistung benötigt wird,
wenn nach einem Dienst gesucht wird, weil nur das den Dienst beschreibende
Profil auf dem Diensteteilnehmerhost heruntergeladen wird und nicht
die ganzen verfügbaren
Dienstebeschreibungen. Erst wenn der Dienst ausgewählt und
der Diensteanbieterhost bestimmt wurde, muß der Diensteteilnehmerhost
auf die Dienstebeschreibung zugreifen, um die Clientanwendung mit
den entsprechenden Parametern zu starten.
-
Das
Verfahren gemäß der vorliegende
Erfindung hat außerdem
den Vorteil, daß eine
sehr detaillierte Dienstebeschreibung dank einer hierarchischen
Organisation des Diensteprofils mit Vererbungsmechanismus erhalten
wird.
-
In
einer bevorzugten Ausführungsform
der vorliegenden Erfindung kann die Clientanwendung auf dem Diensteteilnehmerhost
gemäß der Dienstebeschreibung
aktualisiert werden, die von dem Dienstebeschreibungsserver infolge
der Dienstanfrage zurückgegeben
wurde.
-
Weitere
vorteilhafte Merkmale der Erfindung sind in den anderen abhängigen Ansprüchen definiert.
-
KURZBESCHREIBUNG
DER ZEICHNUNGEN
-
Weitere
Charakteristika und Vorteile der Erfindung werden beim Lesen der
folgenden Beschreibung einer bevorzugten Ausführungsform, die durch nicht
einschränkende
Abbildungen bestimmt ist, und aus den beigefügten Zeichnungen ersichtlich,
in welchen:
-
1 zeigt
ein Kommunikationsnetzwerk, wo das Verfahren gemäß der vorliegenden Erfindung verwendet
werden kann;
-
2 stellt ein Beispiel des Diensteprofils und
der entsprechenden Dienstebeschreibung gemäß der vorliegenden Erfindung
dar;
-
3 veranschaulicht
eine Ausführungsform
des Verfahrens zum Bereitstellen von Diensten in einem Kommunikationsnetzwerk
gemäß der vorliegenden
Erfindung;
-
4 veranschaulicht
eine bevorzugte Ausführungsform
des Verfahrens gemäß der vorliegenden
Erfindung.
-
DETAILLIERTE
BESCHREIBUNG DER ERFINDUNG
-
1 zeigt
ein Kommunikationsnetzwerk, wo das Verfahren gemäß der vorliegenden Erfindung verwendet
werden kann. Das Kommunikationsnetzwerk umfaßt einen Diensteteilnehmerhost 11,
eine Diensteprofil-Datenbank 12, einen Dienstebeschreibungsserver 13 und
zwei Diensteanbieterhosts 14, 15.
-
Der
Diensteteilnehmerhost 11 kann ein Endgerät (z.B.
ein Mobiltelefon oder ein persönlicher
digitaler Assistent oder auch ein Notebook) sein, das mindestens
eine Clientanwendung 111 beinhaltet. Der Einfachheit halber
wird in dem unten ausführlich beschriebenen
Beispiel eine "Druck"-Clientanwendung dargestellt. Andere
Beispiele können
eine Clientanwendung für
digitale Zertifikat-Authentifikation, für sichere Geldüberweisung
im Internet und so weiter sein. Der Diensteteilnehmerhost 11 umfaßt überdies
ein Kommunikationsmodul 112 und eine Schnittstelle I zwischen
der Clientanwendung 111 und dem Kommunikationsmodul 112.
Der Einfachheit halber ist nur eine Clientanwendung im Diensteteilnehmerhost 11 dargestellt.
Man wird verstehen, daß mehrere Clientanwendungen
auf dem Diensteteilnehmerhost 11 für verschiedene Dienste unterstützt werden
können,
die alle eine Schnittstelle zu einem einzelnen Kommunikationsmodul 112 aufweisen.
Als Kommunikationsmodul 112 kann ein Internet-Browser verwendet
werden. Die Diensteanbieterhosts 14, 15 beinhalten
Serveranwendungen und können
eine Client-Server-Kommunikation
mit einer entsprechenden zur Verfügung gestellten Clientanwendung
durchführen.
In dem unten ausführlich
beschriebenen Beispiel ist der Diensteanbieterhost 14 ein
Drucker mit grundlegender Druckfunktionalität, wohingegen der Diensteanbieterhost 15 ein
Drucker mit erweiterter Funktionalität ist.
-
Die
Diensteprofil-Datenbank 12 speichert die Diensteprofile
von verschiedenen Diensten, die im Kommunikationsnetzwerk verfügbar sind.
Im Rahmen der vorliegenden Erfindung ist ein Diensteprofil eine
Datenstruktur, die zur Beschreibung des Dienstetyps verwendete Attribute
und Eigenschaften zur Beschreibung der Beziehungen zwischen verschiedenen
Attributen beinhaltet. Solch ein Diensteprofil stellt eine abstrakte
Beschreibung für
einen Dienstetyp bereit. Eine Sprache, die zum Formalisieren von Diensteprofilen
verwendet wird, ist vorzugsweise eine objektorientierte Sprache,
zum Beispiel, aber nicht beschränkt
auf die Anwendung des Open Knowledged Base Connectivity Model (OKBC).
Die Diensteprofile können
von einem unabhängigen
Dritten ausgegeben oder mit einer Gemeinschaft von Benutzern vereinbart
sein. 3 a zeigt ein Beispiel für ein Diensteprofil, das sich
auf den Dienst "Drucken" bezieht.
-
Der
Dienstebeschreibungsserver 13 beinhaltet Konkretisierungen
von Diensteprofilen, die im Rahmen der vorliegenden Erfindung als
Dienstebeschreibungen bezeichnet sind. Konkretisierungen bedeutet,
daß den
Attributen des Dienstes ein Wert zugewiesen wird, wobei dieser Wert
mit dem Typ des Attributes und den im Diensteprofil spezifizierten
Eigenschaften kompatibel sein muß.
-
Die
Dienstebeschreibungen sollten von verschiedenen Dienstehostanbietern
erzeugt werden und einem in der Diensteprofil-Datenbank 12 gespeicherten
Diensteprofil entsprechen. Sie sollten vorzugsweise auf den Dienstebeschreibungsserver 13 geladen
sein. Die Dienstebeschreibungen, die mit einem Diensteprofil im
Einklang sind, garantieren, daß die
Diensteteilnehmerhosts unter der Bedingung, daß sie über das Wissen des entsprechenden Diensteprofils
verfügen,
besser die Funktionalität
erkennen, die von einem Diensteanbieterhost 14, 15 unterstützt wird
und das Beste daraus machen. Eine Sprache, die zum Formalisieren
der Dienstebeschreibung verwendet wird, ist vorzugsweise mit einem
objektorientierten Modell kompatibel. 3 b zeigt
ein Beispiel für
zwei Dienstebeschreibungen, die sich auf das Diensteprofil "Drucken" beziehen.
-
Man
wird verstehen, daß die
Anzahl jedes Typs der Komponenten (d.h. Diensteteilnehmerhosts,
Diensteanbieterhosts, Datenbank, Dienstebeschreibungsserver), die
das Kommunikationsnetzwerk bilden, gemäß der Topologie des Kommunikationsnetzwerkes
ausgewählt
werden können. Überdies
können
die Diensteprofil-Datenbank 12 und der Dienstebeschreibungsserver 13 am
gleichen Ort sein.
-
Vorzugsweise
sind die Vorteile des Verfahrens gemäß der vorliegenden Erfindung
in zielgerichteten Kommunikationsnetzwerken am nützlichsten. Solche Netzwerke
weisen kein zentrales Steuermodul auf und können dynamisch aufgebaut und
modifiziert sein. Endgeräte,
die angepaßt
sind, um solche zielgerichteten Netzwerke aufzubauen, unterstützen ebenfalls
die Funktionalität
der Netzwerkknoten und können
sowohl Diensteanbieterhosts als auch Diensteteilnehmerhosts sein.
Solche Netzwerke sind ebenfalls unter der Bezeichnung Ad-hoc-Netzwerke
bekannt. Für
den Fachmann wird es jedoch deutlich sein, daß das Verfahren gemäß der vorliegenden
Erfindung ebenfalls auch auf herkömmliche drahtlose Kommunikationsnetzwerke
oder auch festgeschaltete Kommunikationsnetzwerke angewendet werden kann.
-
2a zeigt
ein Beispiel eines Diensteprofils, das sich auf den Dienst "Drucken" bezieht. Das Diensteprofil
umfaßt
der Einfachheit halber drei Attribute und zwei Eigenschaften:
- – Attribut
1: Fußnote
Typ Liste (kein, Datum, Zeit, benutzerdefiniert)
- – Attribut
2: Layout Typ Liste (1 up, 2 up, 4 up, 1 up zweiseitig, 2 up zweiseitig,
4 up zweiseitig)
- – Attribut
3: Kosten pro Seite Typ Float
- – Eigenschaft
1: Kosten pro Seite = f (Anzahl der Seiten, Layout, Fußnote)
- – Eigenschaft
2: Kosten pro Seite < max.
Kosten pro Seiten Gemäß diesem
Diensteprofil können die
Kosten pro Seite für
diesen Dienst von der Anzahl der Seiten, vom angefragten Layout
und vom Contend der Fußnote
abhängig
sein. Dieses Diensteprofil ist in der Diensteprofil-Datenbank 12 gespeichert.
-
2b zeigt
ein Beispiel von zwei Dienstebeschreibungen, die mit dem Diensteprofil
Drucken im Einklang sind.
-
Die
Dienstebeschreibung 1 beschreibt den grundlegenden Druckdienst,
der auf dem Diensteanbieterhost 14 gespeichert ist.
- – Fußnote =
keine
- – Layout
= 1 up
- – Kosten
pro Seite = max. Kosten pro Seite.
-
Dieser
Grunddienst erlaubt nur einen Typ des Layout und weist eine Festkosten-Politik
auf.
-
Die
Dienstebeschreibung 2 beschreibt den erweiterten Druckdienst, der
auf dem Diensteanbieterhost 15 gespeichert ist.
- – Fußnote =
Datum oder Zeit oder benutzerdefiniert
- – Layout
= (1 up oder 2 up oder 1 up zweiseitig oder 2 zweiseitig)
- – Kosten
pro Seiten = max. Kosten pro Seite/Layout in der Zeit zwischen 8.00
und 17.00.
- – Kosten
pro Seiten = max. Kosten pro Seite/(2 * Layout) im übrigen.
-
Dieser
Dienst ermöglicht
das Drucken einer zusätzlichen
Fußnote,
eines Layout mit 1 up, 2 up, 1 up zweiseitigem oder 2 up zweiseitigem
Layout. Die Kostenpolitik ist von der Zeit und vom ausgewählten Layout
abhängig.
-
Beide
Dienstebeschreibungen werden auf dem Dienstebeschreibungsserver 13 gespeichert.
-
3 zeigt
eine Ausführungsform
des Verfahrens zum Bereitstellen von Diensten in einem Kommunikationsnetzwerk
gemäß der vorliegenden Erfindung.
-
Die
gleichen Netzwerkelemente wie in 1 werden
wieder für
die Darstellung des Verfahrens gemäß der vorliegenden Erfindung
benutzt.
-
Das
Verfahren zum Bereitstellen von Diensten gemäß der vorliegenden Erfindung
umfaßt
die folgenden Schritte:
Schritt 31 sollte einmal durchgeführt werden,
bevor das erfindungsgemäße Verfahren
durchgeführt
wird.
-
Schritt 31 besteht
im Registrieren einer Dienstebeschreibung im Einklang mit einem
entsprechenden Diensteprofil auf dem Dienstebeschreibungsserver 13 zusammen
mit einem Identifikator des Diensteanbieterhost 14, 15,
der diesen Dienst unterstützt.
-
Schritt 32 besteht
im Herunterladen eines Diensteprofils auf dem Kommunikationsmodul 112 von
der Diensteprofil-Datenbank 12.
-
Schritt 33 besteht
im Erzeugen einer Anfrage auf dem Kommunikationsmodul 112 unter
Verwendung der Attribute und Eigenschaften des heruntergeladenen
Diensteprofils, das den auf dem Diensteteilnehmerhost benötigten Dienst
beschreibt. Dieser Dienst muß mit
der Clientanwendung 111 kompatibel sein. Eine mögliche Anfrage,
die mit dem unten verwendeten Beispiel kompatibel ist, kann sein:
Anfrage
(Drucken (Fußnote=Datum,
Layout=2up zweiseitig)).
-
Schritt 34 besteht
im Suchen einer Dienstebeschreibung auf dem Dienstebeschreibungsserver 13,
die die Anfrage erfüllt.
Zu diesem Zweck werden die Dienstebeschreibungen vorzugsweise in
einer durchsuchbaren Datenbank gespeichert. Um die Suche in der
Datenbank zu erleichtern, können
die Diensteprofile auf dem Dienstebeschreibungsserver 13 importiert
werden. Dies ist besonders nützlich, wenn
die Diensteprofile und die Dienstebeschreibungen in einer hierarchischen
Baumstruktur organisiert sind.
-
Wenn
eine Dienstebeschreibung oder mehr die Anfrage erfüllen, wird
der entsprechende (bzw. die entsprechenden) Identifikator(en) des
Diensteanbieterhost zurück
an das Kommunikationsmodul 112 gesendet. In diesem Beispiel
wird der Identifikator des Diensteanbieterhost 14, 15 zurückgesendet.
-
Schritt 35 besteht
im Übermitteln
des Identifikators des Diensteanbieterhost, der den benötigten Dienst
unterstützt,
an die Clientanwendung 111.
-
Schritt 36 besteht
im Durchführen
einer Client-Server-Kommunikation
zwischen der Clientanwendung 111 und dem Diensteanbieterhost 14, 15. Während dieser
Client-Server-Kommunikation
wird der Dienst von der Clientseite benötigt und von der Seite des
Diensteanbieterhost ausgeführt.
In der Regel wird eine grafische Benutzeroberfläche (GUI) durch die Clientanwendung
für den
Benutzer gestartet, um die verschiedenen Werte der Attribute des Diensteprofils
auszuwählen.
-
Alternativ
kann als Folge der Anfrage bei Schritt 35 der Dienst automatisch
gestartet werden. Ausführbarer
Code bedeutet, daß der
Identifikator des Diensteanbieterhost enthalten ist und die ausgewählten Attribute
der Anfrage vom Kommunikationsmodul 112 an die Clientanwendung 111 übermittelt und
dort ausgeführt
werden. Dies hat den Vorteil, keine weitere Aktion des Endbenutzers
anzufordern, der bereits ausreichend den von ihm gewünschten Dienst
spezifiziert hat.
-
4 stellt
eine zweite Ausführungsform des
Verfahrens gemäß der vorliegenden
Erfindung dar.
-
In
dieser bevorzugten Ausführungsform
der vorliegenden Erfindung sind die Diensteprofile und die Dienstebeschreibungen
in einer hierarchischen Baumstruktur mit Vererbungsmechanismus organisiert.
Dies ermöglicht
es, die Struktur der durchsuchbaren Datenbank auf dem Dienstebeschreibungsserver 13 zu
optimieren.
-
In
dem vorliegenden Beispiel beinhaltet die hierarchische Baumstruktur
vier Dienstebeschreibungen 41, 42, 43, 44.
Die Dienstebeschreibung 41 ist die Rootbeschreibung und
beinhaltet alle gemeinsamen Attribute und Eigenschaften, die Dienstebeschreibungen 42 und 44 werden
von der Dienstebeschreibung 41 vererbt und beinhalteten
weitere Attribute und Eigenschaften. Die Dienstebeschreibung 43 wird
von der Dienstebeschreibung 42 vererbt.
-
Alle
vier Dienstebeschreibungen 41, ..., 44 beschreiben
Dienste, die sich auf verschiedenen Diensteanbieterhosts 14, 15 befinden.
-
Überdies
ist in dieser bevorzugten Ausführungsform
die Clientanwendung 111, die auf dem Diensteteilnehmerhost 11 gespeichert
ist, im Einklang mit einem Dienst, dessen Dienstebeschreibung 41, 42 sich
auf einer Ebene der hierarchischen Baumstruktur befindet, die höher als
die Dienstebeschreibung 43 des Diensteteilnehmerhost 11 ist,
der den Dienst benutzen möchte.
-
Zum
Beispiel ist die Clientanwendung 111 im Einklang mit der
Dienstebeschreibung 41 und der vom Diensteteilnehmerhost 11 benötigte Dienst
ist im Einklang mit der Dienstebeschreibung 43.
-
In
dieser Ausführungsform
sind die Computercodemittel 412, 413 der Clientanwendung
mit den Dienstebeschreibungen auf den verschiedenen Ebenen der Hierarchie
verknüpft.
-
Alle
Computercodemittel können
in einer Tabelle gespeichert werden, wobei jede Dienstebeschreibung
auf den Eintrag der Tabelle verweist, die die entsprechenden Computercodemittel
enthält.
-
Die
Computercodemittel 412 bzw. 413 sind dafür bestimmt,
um die Clientanwendung 111 zu aktualisieren, so daß sie mit
der Dienstebeschreibung 42 bzw. 43 im Einklang
sein wird, die eine niedrigere Ebene in der Hierarchie der Dienstebeschreibung
als die Dienstebeschreibung 41 aufweist, der sie entsprechen
muß.
-
In
dem Verfahren gemäß der vorliegenden Ausführungsform
werden die mit Bezug auf 3 beschriebenen Schritte 31 bis 34 auf
die gleiche Weise durchgeführt.
In dem Beispiel unten hat die Dienstebeschreibung 43 die
Anfrage erfüllt,
die vom Dienstenutzer 11 gesendet wurde, und ein Identifikator
des Diensteanbieterhost 14 wurde an das Kommunikationsmodul
des Diensteteilnehmerhost 11 bei Schritt 34 zurückgesendet.
-
Außerdem werden
die Schritte A1 bis A4 nach dem Schritt 34 durchgeführt.
-
Der
Schritt A1 besteht im Herunterladen der Computercodemittel 412, 413 auf
dem Diensteteilnehmerhost 11, die notwendig sind, um die
Clientanwendung 111 zu aktualisieren, so daß sie mit
der Dienstebeschreibung 43 im Einklang sein wird. In einer
ersten Ausführungsform
können
die ganzen Computercodemittel direkt vom Dienstebeschreibungsserver
auf den Diensteteilnehmerhost 11 heruntergeladen werden.
-
Alternativ
können
mehrere Delta-Aktualisierungen nacheinander notwendig sein, um die
Aktualisierung durchzuführen.
Zum Beispiel eine erste Aktualisierung, um die Clientanwendung 111 von
der Dienstebeschreibung 41 auf die Dienstebeschreibung 42 zu
erweitern und eine zweite Aktualisierung, um die Dienstebeschreibung 42 auf
die Dienstebeschreibung 43 zu erweitern.
-
Der
Schritt A2 besteht im Darstellen einer grafischen Benutzeroberfläche für den Benutzer,
die die Charakteristika der Clientanwendung 111 und der heruntergeladenen
Computercodemittel berücksichtigt.
-
Der
Schritt A3 besteht im Durchführen
einer normalen Client-Server-Kommunikation zwischen der Clientanwendung,
die durch die Computercodemittel aktualisiert wurde, und dem Diensteanbieterhost 14,
der den durch die Dienstebeschreibung 43 beschriebenen
Dienst unterstützt.
-
Der
Schritt A4 besteht nach der Beendigung der Client-Server-Kommunikation
im Löschen
der Computercodemittel vom Diensteteilnehmerhost und Zurückkehren
zu der ursprünglichen
Clientanwendung 111. Dieser Schritt ist optional, wird
aber empfohlen, um die Größe der Clientanwendung 111 möglichst
klein zu halten (d.h. nur kompatibel mit der Rootdienstebeschreibung 41).
-
Diese
Ausführungsform
bietet die Möglichkeit,
Dienste flexibel bereitzustellen, die mit der ausgewählten Dienstebeschreibung
nicht vollständig
im Einklang sind.