DE60306186T2

DE60306186T2 - Verfahren und system zur anordnung von dienste in einer webdienstarchitektur

Info

Publication number: DE60306186T2
Application number: DE60306186T
Authority: DE
Inventors: Robert Christchurch HARRIS
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2002-10-24
Filing date: 2003-04-28
Publication date: 2007-04-19
Anticipated expiration: 2023-04-29
Also published as: AU2003227887A1; KR100745480B1; KR20050048679A; JP4223004B2; WO2004038621A1; GB0224805D0; ATE330296T1; EP1556807B1; JP2006504172A; CN1689019A; CN100568227C; US8560332B2; EP1556807A1; DE60306186D1; US20130346581A1; US20060112367A1

Description

Diese Erfindung bezieht sich auf ein Verfahren und System für die Rangzuweisung in einer Webdienst-Architektur. Insbesondere bezieht sich die Erfindung auf eine Webdienst-Architektur mit einer Hierarchie von Dienstanbietern, bei der die Rangfolge durch den Aufruf er auf der obersten Ebene angegeben wird.
Webdienste werden in dem Dokument mit dem Titel „Web Services Conceptual Architecture (WSCA 1.0)" der IBM Software Group vom Mai 2001 beschrieben. Webdienste stellen ein Modell für den Datenaustausch zwischen Programmen bereit, das auf bestehenden und neu aufkommenden Standards wie HTTP (Hypertext Transfer Protocol), Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) und Universal Description, Discovery and Integration (UDDI) aufbaut.
Ein Webdienst wird durch eine Schnittstelle beschrieben, die eine Zusammenstellung von Funktionen beschreibt, auf die über eine standardisierte XML-Nachrichtenübertragung innerhalb eines Netzwerks zugegriffen werden kann. Ein Webdienst wird durch eine standardisierte, formale XML-Darstellung beschrieben, die als Dienstbeschreibung bezeichnet wird. Die Dienstbeschreibung deckt alle Einzelheiten ab, die für das Zusammenwirken mit dem Dienst erforderlich sind, darunter Nachrichtenformate, Transportprotokolle und Standort. Die Schnittstelle verbirgt die Einzelheiten der Dienstausgestaltung, so dass er unabhängig von der Hardware- oder Softwareplattform, auf der er realisiert ist, und unabhängig von der Programmiersprache, in der er geschrieben wurde, ausgeführt werden kann. Er ist darüber hinaus unabhängig von der Hardware- oder Softwareumgebung des Aufrufers. Auf diese Weise können auf Webdiensten beruhende Anwendungen lose miteinander verbundene, komponentenbezogene und technologieübergreifende Realisierungen sein, die innerhalb eines Netzwerks veröffentlicht, angeordnet und aufgerufen werden können.
Webdienste werden in einem Netzwerk realisiert. Dabei kann das Netzwerk ein öffentlich zugängliches Netzwerk wie beispielsweise das Internet oder aber ein Intranet oder eine beliebige andere Art von Netzwerk sein. Über das Internet verfügbare Webdienste verwenden gängige Netzwerkprotokolle. Bei derartigen Protokollen kann es sich um HTTP oder andere Internet-Protokolle wie SMTP oder FTP handeln. Andere Netzwerke (z.B. Intranets) können zuverlässige Infrastrukturen für den Nachrichtenaufruf wie MQSeries, COBRA usw. verwenden.
Das beschriebene Verfahren und System bezieht sich auf eine Erweiterung des UDDI-/WSDL-Protokolls und der XML-/SOAP-Syntax, um so Funktionen bereitzustellen, die im Rahmen der Webdienst-Architektur derzeit nicht zur Verfügung stehen.
Dabei wird auf die folgenden Dokumente verwiesen, die unter www.uddi.org verfügbar sind:

UDDI 2.0 Data Structure Reference
UDDI 2.0 API Specification
UDDI 2.0 Operators Specification
Web Services Description Language (WSDL) 1.1

Im Rahmen von Webdiensten besteht das Ziel von UDDI darin, anhand einer Verzeichnis- oder Registrierungssuche einen offenen Zugriff auf Funktionen bereitzustellen. Diese Dienste werden durch den WSDL-Bestandteil beschrieben und durch die XML-/SOAP-Funktion aufgerufen. Die Einbindung des Aufrufers in den Dienst ist dynamisch und nicht festgelegt. Die Offenheit ist dadurch gegeben, dass das Verzeichnis frei zugänglich ist und keine Beschränkungen dafür gelten, wie die Suche oder Auswahl erfolgt. UDDI erfüllt diese Zielsetzung hervorragend, bringt jedoch Nachteile z.B. hinsichtlich der Dienstqualität mit sich.
In der Veröffentlichung „Modeling of Service-Level Agreements for Composed Services" von Daly et.a., Lecture Notes in Computer Science, Bd. 2506 vom 21. Oktober 2002, Seite 4 bis 15, wird die Entwicklung von Garantien für die Leistung eines zusammengesetzten Dienstes ausgehend von den Garantien erörtert, die von den Diensten auf einer niedrigeren Ebene einer Diensthierarchie bereitgestellt werden.
Die britische Patentanmeldung GB 2 349 715 beschreibt einen Angebotsmechanismus für Dienstumgebungen, bei dem das Dienstniveau ausgehandelt wird. Die Auswahl des Kunden beruht dabei auf den Kosten und dem Niveau des angebotenen Dienstes.
Das beschriebene Verfahren und das System stellen Mittel bereit, mit dem Aspekte der Dienstqualität und andere die Auswahl beeinflussende Faktoren in die UDDI-/WSDL-Thematik aufgenommen werden können.
Bei Webdiensten wird die Software anhand eines Verzeichnisses oder einer Registrierung aus Einzelkomponenten zusammengesetzt. Der UDDI zugrunde liegende Gedanke besteht darin, dass eine Anforderung im WSDL-Format an einen Verzeichnis- oder Registrierungsserver gesendet wird, um einen Dienst auszuwählen. Diese Dienstauswahl kann nach bestimmten allgemein anwendbaren Kriterien erfolgen, zu denen beispielsweise die den Dienst bereitstellende Firma und die zugehörige Funktion gehören. Diese Auswahlinformationen sind sehr allgemein gehalten; sie sind für alle Benutzer identisch und enthalten nichts, was für den Urheber der Dienstanforderung spezifisch wäre.
Das beschriebene Verfahren und System stellt ein Mittel bereit, mit dem urheberspezifische Kriterien die Suche beeinflussen können. Im Gegensatz zu bekannten Webdiensten nach bisherigem Stand der Technik wird die Auswahl des Dienstes durch einen Urheber oder Aufruf er der Dienstauswahl beeinflusst.
Das Folgende ist ein praktisches Beispiel. Mit der Software eines Benutzers soll ein Buch gekauft werden. Der Benutzer führt eine Suche in einem Verzeichnis unter der Kategorie „Buchhändler" (Book Sellers) durch und erhält eine Liste von Unternehmen, die diese Dienstleistung anbieten. Nun hat der Benutzer jedoch Rabatte mit beispielsweise zwei Anbietern vereinbart und möchte daher, dass die Bestellanfrage zunächst an diese beiden und anschließend an einen dritten Anbieter geschickt wird. Hierfür filtert der Benutzer die bei der Suche zurückgegebene Liste der Unternehmen, da die Suche die Daten direkt an den Benutzer zurückgegeben hat und der Benutzer genau bestimmen kann, was als Nächstes geschieht.
Anders ist der Fall gelagert, wenn die Bestellanfrage für ein Buch im Rahmen der Funktion eines Dienstes erfolgt, der von einem Dritten bereitgestellt wird. So möchte der Benutzer unter Umständen eine Bibliothek mit Büchern zum Thema „StarTrek" erstellen. Der Benutzer verwendet eine Auswahl „Bibliothek erstellen" (Build a library) und erhält eine Liste der in Frage kommenden Verkäufer. Der Benutzer sendet dann eine Anforderung „Bibliothek zum Thema 'StarTrek' erstellen" (Get-me-a-library-for-StarTrek) an den Anbieter, der diese Aufgabe erledigen soll. Allerdings kann der Benutzer in diesem Fall nicht mehr seine Liste bevorzugter Verkäufer nutzen, da die Funktion des Buchkaufs nun von einem Dritten übernommen wurde. Dieser Dritte verwendet nun seine bevorzugten Anbieter anstelle derjenigen des Benutzers.
Ein Ergebnis der beschriebenen Erfindung stellt eine Art und Weise bereit, mit der sich Bücher (und andere Waren) unter Verwendung der bevorzugten Verkäufer des Benutzers und nicht durch Zwischenhändler erwerben lassen.
Das beschriebene Verfahren und das System beziehen sich darauf, wie WSDL/UDDI-Anforderungen in Abhängigkeit von der Präferenz des Urhebers beeinflusst werden. Dabei werden die Bedingungen, welche die Präferenzen eines Benutzers beeinflussen, nicht erörtert und bleiben dem Benutzer selbst überlassen. Zu den Beispielen für Bedingungen, die eine Benutzerpräferenz beeinflussen können, gehören standardmäßige Kriterien wie Kosten, Leistungsfähigkeit, Geschwindigkeit und Zuverlässigkeit.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren für die Rangzuweisung von Diensten in einer Webdienst-Architektur mit einer Hierarchie von Diensten bereitgestellt, wobei ein Dienst auf einer ersten Ebene der Hierarchie auf eine Anforderung von einem Ausgangs-Dienstanforderer reagiert, um einen Dienst auf einer niedrigeren Ebene der Hierarchie anzufordern, wobei das Verfahren Folgendes umfasst: die Anforderung. von mindestens einem ersten Dienst auf einer ersten Ebene der Hierarchie und die Angabe einer Präferenz hinsichtlich einem oder mehreren Diensten durch den Ausgangs-Dienstanforderer; die Verwendung eines Verzeichnisses durch jeden angeforderten Dienst auf jeder Ebene der Hierarchie, um so eine Gruppe von möglichen Diensten auf einer niedrigeren Ebene zu finden, um den angeforderten Dienst auszuführen; und eine Rangzuweisungseinheit (ranking machine), die über einen ausgewählten Algorithmus auf Grundlage der Präferenz verfügt, um den ausgewählten Algorithmus auf jeder Ebene der Hierarchie auf die Gruppe der möglichen Dienste auf einer niedrigeren Ebene anzuwenden, um so eine Abfolge von bevorzugten Diensten bereitzustellen.
Dabei kann es sich bei den Diensten auf einer niedrigeren Ebene um Dienstanforderer oder Dienstanbieter handeln.
Bei einer Ausführungsform kann die Gruppe von möglichen Diensten auf einer niedrigeren Ebene von dem Verzeichnis an die Rangzuweisungseinheit weitergegeben und von der Rangzuweisungseinheit eine bevorzugte Abfolge an das Verzeichnis zurückgegeben werden. Dabei ist der Schritt der Weitergabe an die Rangzuweisungseinheit für den Dienst, der das Verzeichnis verwendet, möglicherweise nicht sichtbar.
Bei einer anderen Ausführungsform kann die Gruppe der Dienste auf einer niedrigeren Ebene von dem Dienst, der das Verzeichnis verwendet, an die Rangzuweisungseinheit gesendet und eine bevorzugte Abfolge von der Rangzuweisungseinheit an den Dienst zurückgegeben werden.
Dabei kann an den Dienst, der das Verzeichnis verwendet, ein einziges Ergebnis oder eine Abfolge von Ergebnissen zurückgegeben werden.
Vorzugsweise sind Dienstaufrufe auf einer niedrigeren Ebene der Hierarchie für Dienste auf einer höheren Ebene nicht sichtbar.
Dabei kann der Ausgangs-Dienstanforderer den Diensten mit seiner Präferenz eine Rangfolge zuweisen, in welcher er die Dienste nutzen möchte, wobei er Dienste von der Nutzung ausschließen und/oder andere die Auswahl beeinflussende Kriterien bereitstellen kann.
Dabei kann die Präferenz des Ausgangs-Dienstanforderers auf Dienstqualitätskriterien wie Kosten, Leistungsfähigkeit, Geschwindigkeit und Zuverlässigkeit beruhen.
Im Falle einer Präferenz des Ausgangs-Dienstanforderers kann die Präferenz Vorrang vor einer Auswahl durch den Dienst haben, der das Verzeichnis verwendet. Falls der bevorzugte Dienst nicht zur Verfügung steht, kann ein nachfolgender Dienst erhalten werden, indem auf die Präferenz des Ausgangs-Dienstanforderers Bezug genommen wird.
Sollte keine Präferenz des Ausgangs-Dienstanforderers gespeichert sein, kann die Auswahl durch den Dienst vorgenommen werden, der das Verzeichnis verwendet.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird eine Webdienst-Architektur bereitgestellt, die Folgendes umfasst: einen Ausgangs-Dienstanforderer; eine Hierarchie von Diensten, wobei ein Dienst auf einer ersten Ebene der Hierarchie auf eine Anforderung von einem Ausgangs-Dienstanforderer reagiert, um einen Dienst auf einer niedrigeren Ebene der Hierarchie anzufordern; ein Verzeichnis für das Finden von Diensten in der Hierarchie; eine Rangzuweisungseinheit mit einem Mittel für die Anwendung eines ausgewählten Algorithmus für Dienste, darauf beruhend, dass der Ausgangs-Dienstanforderer eine Präferenz hinsichtlich einem oder mehreren Diensten angibt; wobei das Verzeichnis auf jeder Ebene der Hierarchie eine Gruppe von möglichen Diensten auf einer niedrigeren Ebene erkennt und die Rangzuweisungseinheit den ausgewählten Algorithmus auf jeder Ebene der Hierarchie auf die Gruppe von möglichen Diensten auf einer niedrigeren Ebene anwendet, um so eine Abfolge der bevorzugten Dienste bereitzustellen.
Die Rangzuweisungseinheit ist dabei vorzugsweise über einen Anschluss mit dem Verzeichnis verbunden, und die Gruppe von möglichen Diensten wird von dem Verzeichnis an die Rangzuweisungseinheit weitergegeben, während die Abfolge der bevorzugten Dienste von dem Verzeichnis an die Rangzuweisungseinheit zurückgegeben wird.
Dabei kann ein Dienst auf einer ersten Ebene einen Dienst auf einer niedrigeren Ebene mit Hilfe eines UDDI-Verzeichnisses finden. Die Rangzuweisungseinheit kann über einen Anschluss zu dem UDDI-Verzeichnis verfügen und kann Datenströme verarbeiten, wobei tModel-Datensequenzen in eine ausgewählte Gruppe von tModels umgewandelt werden.
Jede UDDI-Operation kann an die Rangzuweisungseinheit weitergegeben und als eine Abfolge zurückgegeben werden, die der Präferenz des Dienstanforderers entspricht.
Der zugrunde liegende UDDI-Anwendungscode kann die Weitergabe durchführen und den Speicherort der Rangzuweisungseinheit an den nachfolgenden XML-Datenstrom anhängen.
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Computerprogrammprodukt für eine Webdienst-Architektur mit einer Hierarchie von Diensten bereitgestellt, wobei ein Dienst auf einer ersten Ebene der Hierarchie auf eine Anforderung von einem Ausgangs-Dienstanforderer reagiert, um einen Dienst auf einer niedrigeren Ebene der Hierarchie anzufordern, wobei das Computerprogrammprodukt computerlesbaren Programmcode für die Durchführung der folgenden Schritte als Reaktion darauf umfasst, dass der Ausgangs-Dienstanforderer mindestens einen ersten Dienst auf einer ersten Ebene der Hierarchie anfordert und eine Präferenz hinsichtlich einem oder mehreren Diensten angibt; wobei jeder angeforderte Dienst auf jeder Ebene der Hierarchie ein Verzeichnis verwendet, um so eine Gruppe von möglichen Diensten auf einer niedrigeren Ebene zu finden und den angeforderten Dienst auszuführen; und eine Rangzuweisungseinheit, die über einen ausgewählten Algorithmus auf Grundlage der Präferenz verfügt, um den ausgewählten Algorithmus auf jeder Ebene der Hierarchie auf die Gruppe der möglichen Dienste auf einer niedrigeren Ebene anzuwenden, um so eine Abfolge von bevorzugten Diensten bereitzustellen.
Im Folgenden werden als Beispiel dienende Ausführungsformen der vorliegenden Erfindung beschrieben, die sich auf die beigefügten Zeichnungen beziehen, wobei:
1 eine schematische Darstellung eines Webdienst-Modells ist;
2 eine schematische Darstellung eines Webdienst-Stapels ist;
3 ein Blockschaubild einer UDDI-Datenstruktur ist;
4A ein schematisches Blockschaubild einer Webdienst-Hierarchie gemäß der vorliegenden Erfindung ist;
4B ein schematisches Blockschaubild einer Webdienst-Architektur gemäß der vorliegenden Erfindung ist;
5A ein Ablaufdiagramm einer Dienstauswahl nach dem Stand der Technik ist;
5B ein Ablaufdiagramm einer ersten Ausführungsform einer Dienstauswahl gemäß der vorliegenden Erfindung ist; und
5C ein Ablaufdiagramm einer zweiten Ausführungsform einer Dienstauswahl gemäß der vorliegenden Erfindung ist.
In dieser Beschreibung wird der Begriff „Webdienste" verwendet. Dies sollte jedoch nicht so verstanden werden, dass ein Webdienst zwangsläufig über das Web (d.h. durch einen Browser) aufgerufen werden muss. Vielmehr kann ein Webdienst in einer beliebigen Art von Netzwerk, z.B. Internet, Intranets, LANs, WANs usw., realisiert werden. Wie weiter oben definiert, stellt ein Webdienst ein Modell für den Datenaustausch zwischen Programmen bereit und wird durch eine Schnittstelle beschrieben, die wiederum die Funktionen des Webdienstes beschreibt.
1 zeigt ein Webdienst-Modell 100 mit drei Rollen:
Dienstanbieter 101, Dienstregistrierung 102 und Dienstanforderer 103. Die Interaktionen beinhalten Veröffentlichungs- 104, Such- 105 und Verbindungsoperationen 106. Die Verbindungsoperation 106 ist ein Zugriffsdatenstrom zwischen den Einheiten einer lose verbundenen Umgebung. Gemeinsam werden diese Rollen und Operationen auf die Webdienst-Artefakte angewendet, bei denen es sich um das Webdienst-Softwaremodul 107 und seine Beschreibung 108 handelt.
Bei einem typischen Szenario übt ein Dienstanbieter 101 eine Wirtsfunktion (Host) für ein über das Netzwerk zugängliches Softwaremodul 107 aus, das eine Realisierung eines Webdienstes ist. Der Dienstanbieter 101 definiert eine Dienstbeschreibung 108 für den Webdienst 107 und veröffentlicht ihn in einer Dienstregistrierung 102. Der Dienstanforderer 103 kann die Dienstbeschreibung 108 oder einen Teil hiervon auch im Rahmen einer Sendeoperation (Push) anstelle einer Empfangsoperation (Pull) direkt vom Dienstanbieter 101 erhalten. Der Dienstanforderer 103 verwendet eine Suchoperation 105, um die Dienstbeschreibung 108 von der Dienstregistrierung 102 zu erhalten, und verwendet die Dienstbeschreibung 108, um eine Verbindung 106 zum Dienstanbieter 101 herzustellen und die Webdienst-Realisierung 107 aufzurufen bzw. mit ihr zu interagieren. Dabei gibt es die Rolle eines Dienstanbieters 101 und eines Dienstanforderers 103, und ein Dienst kann Merkmale von beiden aufweisen.
Der Dienstanbieter 101 ist die Plattform, welche die Wirtsfunktion für den Zugriff auf mindestens den vorgelagerten Teil des Dienstes ausübt. Ein Dienstanforderer 103 ist die Anwendung, die nach einem Dienst sucht und eine Interaktion mit ihm aufruft oder veranlasst. Die Rolle des Dienstanforderers kann von einem Browser, der von einer Person bedient wird, oder von einem Programm ohne Benutzerschnittstelle, z.B. einem anderen Webdienst, übernommen werden. Eine Dienstregistrierung 102 ist eine durchsuchbare Registrierung mit Dienstbeschreibungen 108, in der Dienstanbieter 101 ihre Dienstbeschreibungen 108 veröffentlichen. Dienstanforderer 103 suchen Dienste und erhalten Verbindungsdaten aus der Dienstbeschreibung, um so einen Datenaustausch und die Ausführung mit Blick auf Dienste zu ermöglichen.
Damit sie zugänglich ist, muss eine Dienstbeschreibung 108 so veröffentlicht 104 werden, dass der Dienstanforderer 103 sie finden kann. Bei der Suchoperation 105 ruft der Dienstanforderer 103 eine Dienstbeschreibung 108 direkt ab oder fragt die Dienstregistrierung 102 unter Verwendung eines Prozesses für das Auffinden von Diensten nach dem erforderlichen Diensttyp ab. Bei der Verbindungsoperation 106 ruft der Dienstanforderer 103 während der Laufzeit den Dienst ab oder veranlasst eine Interaktion mit dem Dienst, indem er Verbindungseinzelheiten aus der Dienstbeschreibung 108 verwendet, um einen Kontakt zu dem Dienst herzustellen und ihn auf zurufen.
Die Dienstbeschreibung 108 beinhaltet die Einzelheiten der Schnittstelle für die Realisierung des Dienstes. Dazu gehören Datentypen, Operationen, Verbindungsdaten und Netzwerkstandort. Ebenfalls dazugehören könnte eine Kategorisierung, um so das Auffinden und die Nutzung durch Dienstanforderer 103 zu vereinfachen.
Damit die drei Operationen, d.h. die Veröffentlichung, das Suchen und die Verbindungsherstellung, zusammenwirken können, muss ein Webdienst-Stapel 200 vorhanden sein, der auf jeder Ebene Standards beinhaltet, siehe 2.
Die Grundlage des Webdienst-Stapels 200 bildet die Netzwerkebene 201, da Webdienste über ein Netzwerk zugänglich sein müssen, um von einem Dienstanforderer aufgerufen werden zu können. Zu den Standardtechnologien für die Netzwerkebene 201 des Stapels 200 gehören HTTP, FTP, E-Mail, MQSeries, IIOP usw.
Die nächste Ebene ist eine XML-basierte Nachrichtenebene 202, die für den XML-Benutzer als Grundlage für das Nachrichtenprotokoll steht. Als Verbesserung des XML-Nachrichtenprotokolls kann SOAP verwendet werden.
Die nächste Ebene ist die Dienstbeschreibungsebene 203, bei der es sich um eine Zusammenstellung von Beschreibungsdokumenten handelt. Die Beschreibung lässt sich in drei Gruppen unterteilen: Standort, Aktivität und Schnittstelle. Der Standard für XML-basierte Dienstbeschreibungen ist WSDL. WSDL definiert die Schnittstelle und die zugrunde liegenden Mechanismen der Dienstinteraktion. Das WSDL-Dokument kann durch andere Dienstbeschreibungsdokumente ergänzt werden, um Aspekte einer höheren Ebene des Webdienstes zu beschreiben; so werden beispielsweise für die Beschreibung des Geschäftskontexts zusätzlich zu WSDL-Dokumenten auch UDDI-Datenstrukturen verwendet.
Die ersten drei Ebenen, die Netzwerkebene 201, die XML-basierte Nachrichtenebene 202 und die Dienstbeschreibungsebene 203, werden für die Bereitstellung und Nutzung einer jeden Art von Webdienst benötigt.
Die nächsten beiden Ebenen des Stapels 200 aus 2 sind die Ebenen der Dienstveröffentlichung 204 und der Dienstauffindung 205, die mit einer Reihe von Lösungen realisiert werden können. Jede Handlung, die ein WSDL-Dokument für einen Dienstanforderer zugänglich macht, ist eine Dienstveröffentlichung. Dabei sind in einer öffentlichen UDDI-Registrierung Kopien der Dienstveröffentlichungen gespeichert.
Ein Webdienst kann nur dann gefunden werden, wenn er veröffentlicht wurde, und daher ist die Dienstauffindungsebene 205 abhängig von der Dienstveröffentlichungsebene 204. Dabei entspricht die Vielzahl der Auffindungsmechanismen derjenigen der Veröffentlichungsmechanismen. Jeder Mechanismus, mit dem ein Dienstanforderer auf eine Dienstbeschreibung zugreifen und diese der Anwendung während der Laufzeit zur Verfügung stellen kann, erfüllt die Voraussetzungen für eine Dienstauffindung.
Die oberste Ebene 206 aus 2 bildet die Dienstdatenstrom-Ebene 206, die beschreibt, wie der Datenaustausch, die Zusammenarbeit und die Datenströme zwischen den Diensten erfolgen.
Eine vollständige Webdienst-Beschreibung baut auf der grundlegenden WSDL-Beschreibung des Dienstes auf. Sie enthält Folgendes: das Unternehmen, das die Wirtsfunktion für den Dienst ausübt; die Art des Unternehmens; die dem Dienst zugehörigen Produkte; die Kategorien, denen das Unternehmen oder der Webdienst zugehörig sind; die Aspekte, die einen Anforderer bei der Entscheidung für den Aufruf eines Dienstes beeinflussen könnten; die Schlüsselwörter, die bereitgestellt werden können, um den Dienst leichter auffinden zu können, usw.
UDDI stellt einen Mechanismus für die Speicherung von Webdienst-Beschreibungen bereit. Obwohl UDDI häufig als Verzeichnismechanismus betrachtet wird, definiert es auch einen Datenstrukturstandard für die Darstellung von Dienstbeschreibungsdaten in XML. 3 zeigt einen UDDI-Eintrag 300 mit vier grundlegenden Datenstrukturen.
Ein UDDI-Eintrag beginnt mit einer Geschäftseinheit 301. Eine Geschäftseinheit 301 modelliert Daten zu einem Unternehmen. Die Geschäftseinheit 301 enthält eine Zusammenstellung von Geschäftsdiensten 302 – einen für jeden Webdienst, den das Unternehmen veröffentlichen möchte. Jeder Geschäftsdienst 302 enthält technische und beschreibende Angaben zu dem Webdienst einer Geschäftseinheit. Ein Geschäftsdienst 302 enthält eine Zusammenstellung von Bindungsvorlagen (Binding Templates) 303.
Eine Bindungsvorlage 303 beschreibt die Zugriffsdaten wie beispielsweise die Endpunkt-Adresse und beschreibt ferner, wie der Geschäftsdienst 302 verschiedene technische Spezifikationen nutzt. Eine technische Spezifikation wird als ein tModel 304 modelliert. Ein tModel 304 kann viele verschiedene Konzepte modellieren, zu denen die Art des Dienstes, eine Plattformtechnologie wie HTTPS oder eine Taxonomie gehören können. Für die Realisierung einer Geschäftseinheit 301, eines Geschäftsdienstes 302 und einer Bindungsvorlage 303 wird ein tModel eines vorgegebenen Typs verwendet. Die einem Geschäftsdienst 302 zugehörige Zusammenstellung von Bindungsvorlagen 303 gibt genauen Aufschluss über die Technologien, die der Geschäftsdienst 302 verwendet.
Ein tModel 304 definiert die aufrufende Schnittstelle und die Ergebnisse. Es wird auf einer hohen Ebene in XML und auf einer niedrigeren Ebene über eine API dargestellt, die für den Benutzer nicht sichtbar ist. Ein tModel 304 verfügt über einen eindeutigen Bezeichner, der als Schlüssel (Key) bezeichnet wird. Indem es ein und desselben Schlüssel spezifiziert, unterstützt UDDI die Verwendung eines gegebenen tModels 304 an mehreren Standorten und gewährleistet, dass das Verhalten an den beiden Standorten mit Blick auf die externen Faktoren exakt gleich ist und keine zusätzlichen, plattformspezifischen Rückgabecodes beinhaltet.
Das beschriebene Verfahren und das System enthalten einen Verweis aller UDDI-Operationen auf den Urheber der Anforderung. Wenn die Anforderung von einem Verzeichnis oder einer Registrierung verarbeitet wurde, werden die Ergebnisse zur Filterung an diesen Verweis weitergegeben.
Mit Blick auf 4A wird eine Webdienst-Hierarchie 400 gezeigt. Ein Wurzelknoten der Baumhierarchie 400 ist ein Dienstanforderer 401, der einen Webdienst aufrufen möchte.
Die Baumhierarchie 400 verfügt über eine Anzahl von Dienstebenen 402, 403, die für Zwischendienste stehen, die (direkt oder indirekt) durch den Dienstanforderer 401 aufgerufen werden können, um so den End-Webdienst zu finden, den der Dienstanforderer 401 aufrufen möchte. Die End-Webdienste 404 sind die Blattknoten in der Baumhierarchie 400. Die Ebene 402 kann eine Auswahl eines Dienstes durch den Dienstanforderer 401 sein, und die Ebenen 403 und 404 können eine Auswahl verborgener Teildienste sein, die für den Dienstanforderer 401 nicht sichtbar sind.
Mit Blick auf 4B werden lediglich ausgewählte Dienste 406, 408, 410 auf den einzelnen Ebenen 402, 403, 404 gezeigt. Es wird ein Verzeichnis 411 bereitgestellt, anhand dessen eine Gruppe oder Datensequenz von möglichen Ergebnissen in Form von Diensten oder Dienstanbietern gesucht wird.
Eine Rangzuweisungseinheit 405 wird bereitgestellt, die Einzelheiten zu den Dienstauswahl-Präferenzen des Dienstanforderers 401 speichert. Dies wird in Form eines aus verschiedenen Optionen ausgewählten Algorithmus bereitgestellt, die der Rangzuweisungseinheit 405 zu einem beliebigen relevanten Zeitpunkt vorgelegt werden. Der Dienstanforderer 401 teilt der Rangzuweisungseinheit 405 seine Präferenzen für einen beliebigen Dienstanbieter mit, und ein ausgewählter Algorithmus, der den Präferenzen für Dienstanbieter einen Rang zuweist, wird gespeichert.
Bei einer ersten Ausführungsform hört die Rangzuweisungseinheit 405 an einem Anschluss 412 zu dem Verzeichnis 411 mit. Wenn das Verzeichnis 411 eine Suche ausführt und eine Datensequenz der Ergebnisse erbringt, hört die Rangzuweisungseinheit 405 an dem Anschluss 412 mit, und die Datensequenz der Ergebnisse wird an die Rangzuweisungseinheit 405 gesendet 407. Die Rangzuweisungseinheit 405 wendet ihren ausgewählten Algorithmus auf die Datensequenz der Ergebnisse an und gibt eine Ergebnisabfolge in der bevorzugten Reihenfolge des Dienstanforderers 401 an das Verzeichnis 411 zurück 409. Das Verzeichnis 411 antwortet auf die Suche mit der Ergebnisabfolge, die von der Rangzuweisungseinheit 405 bereitgestellt wurde.
Bei allen Zwischen-Dienstanbietern 402, 403, die Dienste in dem Verzeichnis suchen, wird die Suche an die Rangzuweisungseinheit 405 weitergegeben, welche die Suchergebnisse gemäß den Präferenzen filtert, die für den Dienstanforderer 401 angegeben sind. Wenn in. der Rangzuweisungseinheit 405 eine Präferenz gespeichert ist, nimmt die Rangzuweisungseinheit 405 die Auswahl auf der Grundlage der Präferenz vor, und die Zwischen-Dienstanbieter 402, 403 berücksichtigen die Präferenz, wenn sie einen Dienstanbieter auf einer nächsten Ebene aufrufen.
Im abgebildeten Beispiel aus den 4A und 4B möchte ein Dienstanforderer 401 den Dienst eines Zwischen-Dienstanbieters auf der ersten Ebene 402 in Anspruch nehmen, der die Verwendung eines Dienstes auf einer niedrigeren Ebene beinhaltet. Dabei wird dem Dienstanforderer 401 die Tatsache, dass ein wie auch immer gearteter Dienst auf einer niedrigeren Ebene verwendet wird, jedoch nicht offenbart. Der Dienstanforderer 401 sucht unter Verwendung des Verzeichnisses 411 nach Dienstanbietern auf der ersten Ebene 402 und erhält eine Abfolge von möglichen Dienstanbietern 402. Die Abfolge möglicher Dienstanbieter 402 wurde von der Rangzuweisungseinheit 405 gefiltert, um offensichtlich nicht in Frage kommende Anbieter auszuschließen oder eine bestimmte Auswahl zu erzwingen (d.h., wenn die Datensequenz nur ein Ergebnis beinhaltet). Wenn die Datensequenz mehrere Ergebnisse beinhaltet, wählt der Dienstanforderer 401 einen der Dienstanbieter 406 auf der ersten Ebene 402 aus.
Jede Antwort auf eine Suche, die vom Verzeichnis 411 bereitgestellt wird, erzeugt eine Datensequenz mit in Frage kommenden Anbietern, die von der Rangzuweisungseinheit 405 gefiltert wird. Dabei erfolgt der Verweis an die Rangzuweisungseinheit 405 durch Software des Verzeichnisses 411. Die Rückgabe einer Liste mit Ergebnisse an die Einheit, die eine Suche im Verzeichnis 411 angefordert hat, erfolgt so, als wäre die Rangzuweisungseinheit 405 nicht vorhanden. Die Einheit, welche die Suche angefordert hat, hat die freie Auswahl aus den Ergebnissen, die vom Verzeichnis 411 an sie zurückgegeben wurden, wobei die Ergebnisse jedoch bereits durch die Rangzuweisungseinheit 405 beschränkt wurden.
Der Dienstanforderer 401 tauscht lediglich Daten mit dem Dienstanbieter 406 auf der ersten Ebene 402 aus. Um seine Aufgabe erledigen zu können, verwendet der Dienstanbieter 406 jedoch den Dienstanbieter 408 auf der zweiten Ebene 403, der wiederum den End-Dienst 410 in Anspruch nimmt. Der Dienstanforderer 401 hat keine Kenntnis vom Dienstanbieter 408 auf der zweiten Ebene oder vom End-Dienst 410. Auf ähnliche Art und Weise hat der Dienstanbieter 406 auf der ersten Ebene keine Kenntnis vom End-Dienst 410, der vom Dienstanbieter 408 auf der zweiten Ebene in Anspruch genommen wird.
Der Dienstanbieter 406 auf der ersten Ebene 402 führt eine Suche im Verzeichnis 411 durch, um einen Dienstanbieter 408 auf der zweiten Ebene 403 zu finden. Entsprechend führt der Dienstanbieter 408 auf der zweiten Ebene 403 eine Suche im Verzeichnis 411 durch, um einen End-Dienst 410 zu finden. Bei jeder Suche weist die Rangzuweisungseinheit 405 der vom Verzeichnis 411 gefundenen Datensequenz der Ergebnisse gemäß den Präferenzen des Ausgangs-Dienstanforderers 401 einen bestimmten Rang zu. Die Präferenzen, die von der Rangzuweisungseinheit 405 in ihrem ausgewählten Algorithmus verwendet werden, sind allgemein gültig und unabhängig von der Ebene der Hierarchie.
Bei einer zweiten Ausführungsform gibt das Verzeichnis die Ergebnisse einer Suchanforderung an den Anforderer zurück, wobei es sich dabei um den Ausgangs-Dienstanforderer oder um einen Zwischen-Dienstanbieter handeln kann, und der Anforderer sendet die Datensequenz der Ergebnisse für die Rangzuweisung an die Rangzuweisungseinheit. Die Rangzuweisungseinheit gibt eine Abfolge der Ergebnisse an den Anforderer zurück.
Bei beiden Ausführungsformen können sich die Präferenzen des Dienstanbieters auf Aspekte der Dienstqualität wie Kosten, Leistungsfähigkeit, Geschwindigkeit und Zuverlässigkeit beziehen, oder sie können sich auf eine beliebige andere die Auswahl beeinflussende Präferenz beziehen. Die Präferenz kann den Diensten einen Rang gemäß der Reihenfolge zuweisen, in welcher der Dienstanforderer die Dienste gerne in Anspruch nehmen möchte, oder sie kann einen Dienst gezielt von der Nutzung ausschließen oder aber einen beliebigen anderen Hinweis auf eine Bevorzugung bereitstellen.
Dabei muss der Dienstanforderer nicht erklären, warum eine Präferenz vorhanden ist, und die Präferenzen müssen für die Zwischen-Dienstanbieter weder sichtbar sein noch von diesen verstanden werden. Die Steuerung der Auswahl von Teildiensten liegt nicht mehr beim Anbieter bzw. wird durch den Ausgangs-Dienstanforderer zumindest mitbestimmt.
Beispiel 1
Es folgt ein Beispiel für den Aufruf eines Webdienstes durch einen Dienstanforderer, der als „Benutzer" (User) bezeichnet wird. 5A zeigt, wie eine UDDI-Suchanforderung nach dem Stand der Technik abläuft. Das UDDI-Verzeichnis gibt als ihr Ergebnis eine Datensequenz zurück, die hier als eine (Gruppe) (Set) bezeichnet wird.
Der Benutzer 501 möchte eine Bibliothek erstellen und verwendet das UDDI-Verzeichnis 502, um einen Dienstanbieter 503 zu suchen, der dies übernehmen kann. Der Benutzer 501 sendet eine Anforderung 511 für eine UDDI-Suche an das Verzeichnis 502, um einen Anbieter für die Bibliothekserstellung ausfindig zu machen. In diesem Fall gibt es lediglich einen Dienstanbieter 503 in dieser Kategorie, und somit gibt das Verzeichnis 502 das Ergebnis der Gruppe (Bibliotheksersteller1) (Library Builder1) zurück 512.
Daraufhin sendet der Benutzer 501 eine Anforderung 513 „Bibliothek erstellen" (Build a library) an den Server Bibliotheksersteller1 (LibraryBuilder1) 504. Dieser sucht dann 514, 515 im UDDI-Verzeichnis 502 nach einer Liste von Buchanbietern 505. Das Verzeichnis 502 gibt die Gruppe (Verkäufer1, Vom Benutzer bevorzugter Verkäufer2) (Seller1, UserPreferredSeller2) zurück 516. Der Bibliotheksersteller1 (LibraryBuilder1) 504 wählt danach 517 den ersten Anbieter aus, wobei es sich um den Verkäufer1 (Seller1) 506 handelt, bzw. er wählt den Anbieter mit der seiner Ansicht nach besten Eignung aus, um von diesem das Buch zu kaufen. Als Ergebnis wird das Buch von einer Stelle gekauft 518, die vorteilhaft für den Bibliotheksersteller1 (LibraryBuilder1) ist, bei der es sich jedoch nicht um den bevorzugten Verkäufer des Benutzers handelt, der in diesem Fall vom Benutzer bevorzugter Verkäufer2 (UserPreferredSeller2) 507 lautet.
5B zeigt die gleiche UDDI-Suche wie 5A, jedoch gemäß einer ersten Ausführungsform der vorliegenden Erfindung. Das beschriebene Verfahren und das System machen erforderlich, dass jede UDDI-Anforderung an eine Stelle weitergegeben wird, welche der zurückgegebenen Datensequenz gemäß der Präferenz des Benutzers eine bestimmte Rangfolge zuweisen kann. Dabei ist nicht von Belang, welche Kriterien verwendet werden, wichtig ist lediglich, dass die Rangzuweisung stattfindet.
Somit wird die (Datensequenz) (Bag) als eine <Abfolge> (<Sequence>) zurückgegeben, wobei sich die bevorzugten Elemente am Anfang der Liste befinden. Die Abfolge kann alle Mitglieder der Datensequenz, eine Teilmenge oder auch etwas völlig Anderes beinhalten. Der Verweis erfolgt durch den zugrunde liegenden UDDI-Suchcode (oder anders ausgedrückt, durch die zugrunde liegenden UDDI-APIs). Zusätzliche Codeschritte durch den Aufrufer sind nicht erforderlich.
5B enthält als zusätzliche Komponente die Rangzuweisungseinheit 508, die einen ausgewählten Algorithmus beinhaltet, der die Präferenzen wiedergibt, die der Benutzer 501 mit Blick auf die Buchanbieter 509 angegeben hat.
Der Benutzer fordert das UDDI-Verzeichnis 502 auf, einen Bibliotheksersteller zu suchen 521. Das Verzeichnis 502 findet die Gruppe (Bibliotheksersteller1) (LibraryBuilder1).
Allerdings wird dies dem Benutzer 501 nicht angezeigt, da den darunter liegenden Ebenen von Dienstanbietern bekannt ist, dass einer lokalen Anforderung ohne Verweis noch ein Rang zugewiesen werden muss und dass dies über Konfigurationsoptionen und somit für den Benutzer unsichtbar stattfindet. Somit wird der vom UDDI-Verzeichnis 502 zurückgegebene Datenstrom an die lokale Rangzuweisungseinheit 508 zur Analyse verwiesen 522. Da es nur eine akzeptable Auswahlmöglichkeit gibt, <LibraryBuilder1>, bleiben die Ergebnisse unverändert und werden so zurück zunächst an das UDDI-Verzeichnis 502 gesendet 523, das sie dann an den Benutzer 501 zurückgibt 524.
Im Anschluss daran wählt der Benutzer 501 den ersten (und in diesem Beispiel einzigen) Anbieter 504 aus und ruft die Operation „Bibliothek erstellen" („Build Library") für ihn auf 525. Den darunter liegenden Ebenen ist bekannt, dass dies eine XML-/SOAP-Dienstanforderung ist, und sie hängen somit den Standort der erforderlichen Rangzuweisungseinheit 508 an den XML-Datenstrom an.
Daraufhin fordert 526 der Anbieter Bibliotheksersteller1 (LibraryBuilder1) 504, dass das UDDI-Verzeichnis 502 eine Liste von Buchverkäufern 504 sucht, und hängt den Standort der relevanten Rangzuweisungseinheit 508 an den Datenstrom an. Diese Verzeichnissuche 527 gibt die gespeicherte Gruppe von Buchverkäufern (Verkäufer1, Vom Benutzer bevorzugter Verkäufer2) (Seller1, UserPreferredSeller2) zurück. Die darunter liegenden Ebenen verweisen 528 diese Gruppe dann wie zuvor an die Rangzuweisungseinheit 508. In diesem Fall möchte die Rangzuweisungseinheit 508 die Verwendung des vom Benutzer bevorzugten Buchanbieters 509 durchsetzen und ändert das UDDI-Ergebnis in die Abfolge <Vom Benutzer bevorzugter Verkäufer2> (<UserPreferredSeller2>), bevor sie das Ergebnis an das UDDI-Verzeichnis 502 zurücksendet 529, die das Ergebnis dann als das Ergebnis der Suche 527 an den Bibliotheksersteller 504 zurücksendet 530. In der Folge wird das Buch nun nicht vom Verkäufer1 (Seller1) 506, sondern von dem vom Benutzer bevorzugtenVerkäufer2 (UserPreferredSeller2) 507 bestellt 321, 322.
5C zeigt die gleiche UDDI-Suche wie die 5A und 5B, jedoch gemäß einer zweiten Ausführungsform der vorliegenden Erfindung. Wie in 5B erfordern das beschriebene Verfahren und System, dass jede UDDI-Anforderung an eine Stelle weitergegeben wird, die der zurückgegebenen Datensequenz eine bestimmte Rangfolge zuweisen kann, die den Präferenzen des Benutzers entspricht. Dabei ist nicht von Belang, welche Kriterien verwendet werden, wichtig ist lediglich, dass die Rangzuweisung stattfindet.
Auch hier wird die (Datensequenz) (Bag) als eine <Abfolge> (<sequence>) zurückgegeben, wobei die bevorzugten Elemente am Anfang der Liste stehen. Bei der zweiten Ausführungsform empfängt der Anforderer einer Suche im UDDI-Verzeichnis 502 jedoch die <Abfolge> (<sequence>) der Ergebnisse und gibt sie zur Rangzuweisung an die Rangzuweisungseinheit 508 weiter, und der Anforderer empfängt daraufhin die den Präferenzen des Benutzers 501 entsprechende <Abfolge> (<sequence>) von der Rangzuweisungseinheit 508.
Realisierung
Bei der ersten Ausführungsform hört eine Rangzuweisungseinheit an einem UDDI-/Rangzuweisungseinheitsanschluss mit und verarbeitet die oben erwähnten Datenströme und wandelt dabei eine tModel-Datensequenz in eine ausgewählte Datensequenz von tModels um.
Mit Bezug auf die UDDI-API werden die zehn Verben „find_xx" erweitert, indem der URL-Anschluss der Rangzuweisungseinheit hinzugefügt wird. Beispiel:
ergibt
Mit Bezug auf die SOAP-/XML-Ausführung des Dienstes erfolgt eine Erweiterung um die URL der Rangzuweisungseinheit. Dabei schreibt das UDDI-Paradigma die Weitergabe an darauf folgende UDDI-bezogene Aufrufe vor.
Der Datenstrom wird durch den WSDL-Anbieter eingefügt oder verarbeitet, bzw. die Funktion befindet sich auf jeden Fall entweder auf dem UDDI-Server (als A-Adresse: Anschluss wird bei Suchanforderung weitergegeben) oder in der DLL des Aufrufers, die für die UDDI-Verarbeitung verwendet wird. In jedem Fall führt der UDDI-Suchprozess die Filterung ohne Eingreifen des Aufrufers durch.
Sollte der Dienst, der diese Adresse der Rangzuweisungseinheit empfängt, sie für darauf folgende UDDI-/XML-/SOAP-Operationen nicht weitergeben, stellt dies eine Protokollverletzung dar, und der Dienst verhält sich nicht gemäß den Regeln. Wie bei allen anderen Standards auf diesem Gebiet greift in diesem Fall ein Selbststeuerungsmechanismus.
Es wird jedoch ein neuer Eintrag in die Bindungsvorlage und die Geschäftsdienst-tModels aufgenommen, um anzugeben, ob der Dienst die Regeln eingehalten hat. Dieses Element kann als <RankingSupported/> betrachtet werden. Wenn ein <RANKER>-Element bei dem Aufruf bereitgestellt wird und <RankingSupported/> nicht vorhanden ist, wählen die „find_xx"-APIs kein tModel aus.
Mit Blick auf die API-Ausführung erfolgt dies im Wesentlichen in der Komponente, welche die Wirtsfunktion für das UDDI-Verzeichnis ausübt. Der die Auswahl vornehmende Code wird so angepasst, dass er die neuen API- und tModel-Kennungen unterstützt.
Somit hat diese Beschreibung deutlich gemacht, wie die Verwendung einer Rangzuweisungseinheit zur Verarbeitung von URL-Anforderung, verbunden mit zugehörigen Erweiterungen von UDDI-/WSDL-Protokollen, die neue Funktion für die Auswahl der Präferenz des Urhebers in das UDDI-Paradigma einführt.
Wenn ein Dienstanbieter nicht verfügbar ist und daher ein anderer ausgewählt werden muss, gilt Folgendes. Die eigentlichen Dienste werden auf der Schnittstellenebene (Parameteraufruf) durch ein spezifisches Bindungs-tModel angegeben. Wenn ein spezifischer Dienst gewünscht wird, muss auch ein spezifisches tModel verwendet werden (andernfalls werden viele verschiedene XML-Aufrufe codiert), das als Bindungsvorlage bezeichnet wird. Problematisch ist dies dann, wenn der Anbieter, der das spezifische tModel verwendet, unerwünscht (zu langsam, zu teuer, außer Betrieb) ist und der Code nicht geändert werden kann, um so einen anderen Anbieter mit einer anderen Schnittstelle zu verwenden.
Um das Problem der Umcodierung zu vermeiden, muss ein anderer Anbieter mit genau derselben Schnittstelle verwendet werden; anders ausgedrückt, ein Anbieter, der dasselbe Bindungs-tModel verwendet. Dies ist über eine UDDI-Suche problemlos möglich.
Dabei ist darauf hinzuweisen, dass UDDI öffentliche (d.h. allgemein zugängliche) und private (d.h. aufruferspezifische) Verzeichnisse unterstützt. Dies stellt kein Problem dar, solange sich der gesamte angeforderte Dienst innerhalb des privaten Verzeichnisses befindet (innerhalb derselben Organisation und somit unter Verwendung desselben oder eines replizierten UDDI-Servers), so dass die Präferenz-Thematik durch die Auswahl dessen geregelt werden kann, was in dieses private Verzeichnis aufgenommen wird. Dieser Ansatz scheitert jedoch bei der Verarbeitung einer Anforderung, die über den Rahmen des privaten Verzeichnisses hinausgeht. Das beschriebene Verfahren und System löst dieses Problem.
Ebenfalls zu beachten ist, dass UDDI ein tModel zur Einrichtung von Beziehung zwischen zwei Organisationen (PublisherAssertion) unterstützt. Auf diese Weise sollen Anbieter in einer größeren Einheit zusammengeführt werden. Dies stellt jedoch keine Überschneidung mit dem beschriebenen Verfahren und System dar, da die „PublisherAssertion"-Struktur öffentlich und statisch ist und es keine Gewähr dafür gibt, dass die behauptete Geschäftsbeziehung bestätigt wird.
Verbesserungen und Abänderungen der obigen Inhalte sind möglich, ohne vom Umfang der vorliegenden Erfindung abzuweichen.

Claims

Verfahren für die Rangzuweisung von Diensten in einer Webdienst-Architektur mit einer Hierarchie von Diensten (401, 406, 408, 410), wobei ein Dienst auf einer ersten Ebene der Hierarchie auf eine Anforderung von einem Ausgangs-Dienstanforderer (401) reagiert, um einen Dienst auf einer niedrigeren Ebene der Hierarchie anzufordern, wobei das Verfahren Folgendes umfasst: die Anforderung von mindestens einem ersten Dienst auf einer ersten Ebene der Hierarchie und die Angabe einer Präferenz hinsichtlich eines oder mehrerer Dienste durch den Ausgangs-Dienstanforderer (401); die Verwendung eines Verzeichnisses (411) durch jeden angeforderten Dienst auf jeder Ebene der Hierarchie, um so eine Gruppe von möglichen Diensten auf einer niedrigeren Ebene zu finden, um den angeforderten Dienst auszuführen; und gekennzeichnet durch die Verwendung einer Rangzuweisungseinheit (405), die über einen ausgewählten Algorithmus auf Grundlage der Präferenz verfügt, um den ausgewählten Algorithmus auf jeder Ebene der Hierarchie auf die Gruppe der möglichen Dienste auf einer niedrigeren Ebene anzuwenden, um so eine Abfolge von bevorzugten Diensten bereitzustellen.
Verfahren nach Anspruch 1, wobei es sich bei den Diensten auf einer niedrigeren Ebene um Dienstanforderer oder Dienstanbieter handelt.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei die Gruppe von möglichen Diensten auf einer niedrigeren Ebene von dem Verzeichnis (411) an die Rangzuweisungseinheit (405) weitergegeben und von der Rangzuweisungseinheit (405) eine bevorzugte Abfolge an das Verzeichnis zurückgegeben wird.
Verfahren nach Anspruch 3, wobei der Schritt der Weitergabe an die Rangzuweisungseinheit (405) für den Dienst, der das Verzeichnis (411) verwendet, nicht sichtbar ist.
Verfahren nach Anspruch 1 oder Anspruch 2, wobei die Gruppe der Dienste auf einer niedrigeren Ebene von dem Dienst, der das Verzeichnis (411) verwendet, an die Rangzuweisungseinheit (405) gesendet und eine bevorzugte Abfolge von der Rangzuweisungseinheit (405) an den Dienst zurückgegeben wird.
Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei an den Dienst, der das Verzeichnis (411) verwendet, ein einziges Ergebnis oder eine Abfolge von Ergebnissen zurückgegeben wird.
Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei Dienstaufrufe auf einer niedrigeren Ebene der Hierarchie für Dienste auf einer höheren Ebene nicht sichtbar sind.
Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei der Ausgangs-Dienstanforderer (401) den Diensten mit seiner Präferenz eine Rangfolge zuweist, in welcher der Ausgangs-Dienstanforderer (401) die Dienste nutzen möchte, wobei er Dienste von der Nutzung ausschließt und/oder andere die Auswahl beeinflussende Kriterien bereitstellt.
Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei die Präferenz des Ausgangs-Dienstanforderers (401) auf Dienstqualitätskriterien wie Kosten, Leistungsfähigkeit, Geschwindigkeit und Zuverlässigkeit beruht.
Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei im Falle einer Präferenz des Ausgangs-Dienstanforderers die Präferenz Vorrang vor einer Auswahl durch den Dienst hat, der das Verzeichnis (411) verwendet.
Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei, falls der bevorzugte Dienst nicht zur Verfügung steht, ein nachfolgender Dienst erhalten wird, indem auf die Präferenz des Ausgangs-Dienstanforderers Bezug genommen wird.
Verfahren nach einem beliebigen der Ansprüche 1 bis 9, wobei, wenn keine Präferenz des Ausgangs-Dienstanforderers gespeichert ist, die Auswahl durch den Dienst vorgenommen wird, der das Verzeichnis (411) verwendet.
Webdienst-Architektur, die Folgendes umfasst: einen Ausgangs-Dienstanforderer (401); eine Hierarchie von Diensten (401, 406, 408, 410), wobei ein Dienst auf einer ersten Ebene der Hierarchie auf eine Anforderung von einem Ausgangs-Dienstanforderer (401) reagiert, um einen Dienst auf einer niedrigeren Ebene der Hierarchie anzufordern; ein Verzeichnis (411) für das Finden von Diensten in der Hierarchie, gekennzeichnet durch eine Rangzuweisungseinheit (405) mit einem Mittel für die Anwendung eines ausgewählten Algorithmus für Dienste, darauf beruhend, dass der Ausgangs-Dienstanforderer eine Präferenz hinsichtlich eines oder mehrerer Dienste angibt; wobei das Verzeichnis (411) auf jeder Ebene der Hierarchie eine Gruppe von möglichen Diensten auf einer niedrigeren Ebene erkennt und die Rangzuweisungseinheit (405) den ausgewählten Algorithmus auf jeder Ebene der Hierarchie auf die Gruppe von möglichen Diensten auf einer niedrigeren Ebene anwendet, um so eine Abfolge der bevorzugten Dienste bereitzustellen.
Webdienst-Architektur nach Anspruch 13, wobei es sich bei den Diensten auf einer niedrigeren Ebene um Serviceanforderer oder Serviceanbieter handelt.
Webdienst-Architektur nach Anspruch 13 oder Anspruch 14, wobei die Rangzuweisungseinheit (405) über einen Anschluss (412) mit dem Verzeichnis (411) verbunden ist und die Gruppe von möglichen Diensten von dem Verzeichnis (411) an die Rangzuweisungseinheit (405) weitergegeben und die Abfolge der bevorzugten Dienste von dem Verzeichnis (411) an die Rangzuweisungseinheit (405) zurückgegeben wird.
Webdienst-Architektur nach einem beliebigen der Ansprüche 13 bis 15, wobei ein Dienst auf einer ersten Ebene einen Dienst auf einer niedrigeren Ebene mit Hilfe eines UDDI-Verzeichnisses (411) findet.
Webdienst-Architektur nach Anspruch 16, wobei die Rangzuweisungseinheit (405) über einen Anschluss (412) zu dem UDDI-Verzeichnis (411) verfügt und Datenströme verarbeitet, wobei tModel-Datensequenzen in eine ausgewählte Gruppe von tModels umgewandelt werden.
Webdienst-Architektur nach Anspruch 16 oder Anspruch 17, wobei eine jede UDDI-Operation an die Rangzuweisungseinheit (405) weitergegeben und als eine Abfolge zurückgegeben wird, die der Präferenz des Dienstanforderers entspricht.
Webdienst-Architektur nach einem beliebigen der Ansprüche 16 bis 18, wobei der zugrunde liegende UDDI-Anwendungscode die Weitergabe durchführt und den Speicherort der Rangzuweisungseinheit (405) an den nachfolgenden XML-Datenstrom anhängt.
Computerprogrammprodukt für eine Webdienst-Architektur mit einer Hierarchie von Diensten (401, 406, 408, 410), wobei ein Dienst auf einer ersten Ebene der Hierarchie auf eine Anforderung von einem Ausgangs-Dienstanforderer (401) reagiert, um einen Dienst auf einer niedrigeren Ebene der Hierarchie anzufordern, wobei das Computerprogrammprodukt computerlesbaren Programmcode für die Durchführung der folgenden Schritte als Reaktion darauf umfasst, dass der Ausgangs-Dienstanforderer (401) mindestens einen ersten Dienst auf einer ersten Ebene der Hierarchie anfordert und eine Präferenz hinsichtlich eines oder mehrerer Dienste angibt; wobei jeder angeforderte Dienst auf jeder Ebene der Hierarchie ein Verzeichnis (411) verwendet, um so eine Gruppe von möglichen Diensten auf einer niedrigeren Ebene zu finden, um den angeforderten Dienst auszuführen; und gekennzeichnet durch die Verwendung einer Rangzuweisungseinheit (405), die über einen ausgewählten Algorithmus auf Grundlage der Präferenz verfügt, um den ausgewählten Algorithmus auf jeder Ebene der Hierarchie auf die Gruppe der möglichen Dienste auf einer niedrigeren Ebene anzuwenden, um so eine Abfolge von bevorzugten Diensten bereitzustellen.