DE112011102073B4

DE112011102073B4 - Dienstimplementierung von einem Dienstverzeichnis

Info

Publication number: DE112011102073B4
Application number: DE112011102073.2T
Authority: DE
Inventors: Thomas Jack Bailey; Jonathan Mark Roberts; Kieran Paul Scott; Christopher David Jenkins
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2010-08-16
Filing date: 2011-07-25
Publication date: 2022-02-03
Anticipated expiration: 2031-07-26
Also published as: US20160337458A1; GB2496332A; US11153204B2; WO2012022585A1; US20120158906A1; GB201301505D0; TW201220189A; US20200220809A1; DE112011102073T5; US20160366050A1; US20120042040A1; JP2013541069A; US10708177B2; US9459924B2; US10700963B2; US9483312B2

Abstract

Verfahren, das von einem Dienstverzeichnis in einer service-orientierten Umgebung zum Bereitstellen eines Dienstes in der Umgebung durchführbar ist, wobei das Verfahren die Schritte aufweist:- Empfangen einer Anforderung für einen Dienst von einem Dienstanforderer in der service-orientierten Umgebung;- Prüfen der Einzelheiten des angeforderten Dienstes wie im Dienstverzeichnis registriert;- gekennzeichnet durch:- Senden der Anforderung an einen oder mehrere Dienstanbieter, um einen neuen Dienst bereitzustellen, als Reaktion darauf, dass der angeforderte Dienst nicht registriert ist; und- Aktualisieren des Dienstverzeichnisses mit dem neuen Dienst und Benachrichtigen des Dienstanforderers, dass der Dienst zur Verfügung steht, als Reaktion darauf, dass ein Dienstanbieter den neuen Dienst bereitstellt;- als Reaktion darauf, dass der angeforderte Dienst nicht registriert ist,◯ Senden der Dienstanforderung an eines oder mehrere nachrangige Dienstverzeichnisse, um einen Dienstanbieter für den Dienst bereitzustellen;◯ Senden lokalisierter Dienstinformationen von dem ersten Dienstverzeichnis an ein oder mehrere nachrangige Dienstverzeichnisse, wobei Dienstanbieter lokalisiert werden durch die Dienstinformationen, die dem angeforderten Dienst zugeordnet sind, so dass es für das eine oder die mehreren nachrangigen Dienstverzeichnisse möglich ist, die durch das erste Dienstverzeichnis lokalisierten Dienstinformationen zu verwenden, um einen Dienstanbieter auszuwählen; und- Vermitteln zwischen dem Dienstanforderer und dem Dienstanbieter, wobei der Dienstanforderer den eigentlichen Dienstendpunkt des Dienstanbieters nicht empfängt, sondern den Dienst über die Dienstverwaltungsschicht verwendet.

Description

Diese Erfindung bezieht sich auf ein Verfahren und eine Vorrichtung für eine dienstbasierte Implementierung (deployment) in einem System, das auf einer service-orientierten Architektur (SOA) beruht. Die Erfindung bezieht sich dabei insbesondere auf ein Verfahren und eine Vorrichtung zum Lokalisieren von Dienstendpunkten (service endpoints) von einem Dienstverzeichnis (service registry).
HINTERGRUND
Eine service-orientierte Architektur (SOA) ist ein unternehmensorientierter Ansatz einer IT-Architektur, der die Integration von Unternehmensprozessen als verknüpfte, wiederholbare Unternehmensaufgaben oder Dienste laut Definition in Dienstdokumenten (service documents) unterstützt. Ein Dienstdokument ist ein grundlegender Baustein einer SOA, das festlegt, wie ein Dienst genutzt werden kann, wie auf ihn zugegriffen werden kann und wie er mit anderen Diensten verwaltet werden kann. Analytiker, Architekten und Entwickler verwenden Dienstdokumente in einer Entwicklungsphase des SOA-Lebenszyklus, um Dienste zum Wiederverwenden zu lokalisieren und die Auswirkungen von Änderungen auf Dienstkonfigurationen zu bewerten. Dienstdokumente werden verschiedentlich als Metadaten, Objekte, Beschreibungen, Entitäten und Artefakte beschrieben, die Informationen über einen Dienst, darunter eine Dienstbeschreibung und ein Dienstendpunkt, speichern. Ein Dienstendpunkt ist eine eindeutige, von einem Computer adressierbare Position für den Dienst. Dienstdokumente werden in einem Dienstverzeichnis in einem SOA-System gespeichert. Informationen in jedem Dienstdokument, darunter die Dienstendpunkte, werden in einem als Zerkleinern (shredding) bezeichneten Prozess indexiert. Das Indexieren von Dienstdokumenten, um eine Liste aller Dienste und Dienstendpunkte zu verwalten, ist Teil eines Verwaltens von Diensten auf Anforderung. Ein Beispiel eines Dienstverzeichnisses ist das IBM® WebSphere® Service Registry & Repository. Das Verzeichnis kann hervorheben, dass mehrere Endpunkte zur Verfügung stehen, um die Dienstanforderung weiterzuleiten. Wenn eine Anforderung eingeht, kann das Verzeichnis seine Kenntnis der Topologie der vorhandenen Dienstarchitektur nutzen und feststellen, dass der angeforderte Dienst entweder nicht zur Verfügung steht oder unterhalb der vereinbarten Dienstgüte (service level) liegt. IBM und WebSphere sind Warenzeichen der International Business Machines Corporation, die bei vielen Gerichtsständen weltweit eingetragen sind.
Installierte Dienste mit einem registrierten Dienstendpunkt können aufgerufen werden, während Dienste ohne einen registrierten Endpunkt nicht aufgerufen werden können. Dienste sind bei einem Dienstanbieter mit einem festen oder schnell zur Verfügung stehenden Dienstendpunkt installiert, der in einem Dienstdokument definiert und von einem Dienstverzeichnis indexiert wird. Viele Dienstanbieter haben jedoch feste Ressourcen und müssen Diensten mit hoher Nachfrage den Vorrang vor Diensten mit geringer Nachfrage geben; aus diesem Grund stehen nicht alle Dienste gleichzeitig zur Verfügung.
Ein Dienst mit geringer Nachfrage kann von einem Dienstanbieter deinstalliert und aus den aktiven Diensten des Dienstanbieters entfernt werden; jeder dem Dienst zugeordnete Dienstendpunkt wird von dem Verzeichnis entfernt und der Dienst wird archiviert, so dass er neu installiert und mit einem neuen Dienstendpunkt eingerichtet werden muss. Für einen Kunden wäre es nützlich, wenn beim Anfordern eines deinstallierten Dienstes keine Verzögerung oder kein Unterschied bei dem Dienst auftreten würde. Ein Dienst mit geringer Nachfrage oder ein deinstallierter Dienst kann manchmal als ein veralteter oder unterverwendeter Dienst bezeichnet werden.
Anstatt einer Deinstallation kann der Dienstanbieter die Verarbeitungspriorität eines Dienstes mit geringer Nachfrage herabsetzen oder die dem Dienst mit geringer Nachfrage bereitgestellte Verarbeitungsbandbreite auf andere Weise verringern. Dadurch könnte die vom Anforderer des Dienstes wahrgenommene Qualität des Dienstes bis zu einem Punkt verschlechtert werden, wo der Dienst nicht mehr das ist, was der Anforderer des Dienstes wollte. In einigen Fällen würde die Verschlechterung der Qualität den Bestimmungen des Dienstvertrags zuwiderlaufen. Für einen Anforderer eines Dienstes wäre es nützlich, eine gewünschte Qualität des Dienstes zu erhalten und keine Verzögerung oder keinen Unterschied bei der Qualität des Dienstes festzustellen, auch wenn die Verarbeitungspriorität für den angeforderten Dienst verringert wurde und dieser neu konfiguriert werden musste.
In der US-Patentschrift 7,171,470 B2 (Doyle, R. P. et al „Grid Service Scheduling of Related Services using Heuristics“), 30. Januar 2007, werden ein Verfahren und System zum Planen von Dienstinstanzen in einem Rechner-Grid beschrieben, um mindestens einen Teil einer angeforderten Transaktion zu verarbeiten.
In Spiess, Patrik et al.: „SOA-based integration of the internet of things in enterprise services“, Web Services, 2009, ICWS 2009, IEEE International Conference on IEEE 2009, S. 968 - 975, wird eine Architektur vorgeschlagen, die eine „Internet der Dinge“-Infrastruktur eng mit den Diensten eines Unternehmens verbinden kann.
In US 2004 / 0 236 633 A1 wird eine Registry beschrieben, mit der Service-Anfragen dynamisch bearbeitet werden können.
Ausgehend von diesem Stand der Technik stellt sich die Erfindung die Aufgabe, Dienstanfragen auch nach einem ersten Fehlversuch bei der Suche nach einem Dienstanbieter zu befriedigen.
Diese Aufgabe wird erfindungsgemäß gelöst durch das Verfahren, das von einem Dienstverzeichnis in einer service-orientierten Umgebung zum Bereitstellen eines Dienstes in der Umgebung durchführbar ist, nach Anspruch 1, durch das Dienstverzeichnis in einem System mit einer service-orientierten Architektur zum Bereitstellen eines Dienstes in dem System nach Anspruch 8 und durch das Computerprogrammprodukt nach Anspruch 16 sowie durch das Computerprogramm, das in einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers ladbar ist und Teile eines Softwarecodes aufweist, nach Anspruch 24. Bevorzugte Ausführungsformen der Erfindung sind Gegenstand der jeweiligen Unteransprüche.
ZUSAMMENFASSUNG DER ERFINDUNG
Die Erfindung beinhaltet die folgenden Teilaspekte. Demnach fordert ein Dienstverzeichnis an, dass ein Dienst (oder zusätzliche Instanzen des Dienstes) von einem Dienstanbieter zur Verfügung gestellt wird (bzw. werden) und durch Cloud-Computing bereitgestellt werden kann, zum Beispiel indem ein virtuelles Maschinenabbild, das den Dienst enthält, in eine zur Verfügung stehende Hardware gestellt wird. Der neue Dienstendpunkt wird zu dem Verzeichnis hinzugefügt, und ein Enterprise Service Bus (ESB) kann zu dem neuen Endpunkt (zusätzlich zu vorhandenen Endpunkten) leiten. Der Dienst bleibt implementiert, bis ein Zeitlimit- oder Nutzungswert erreicht wird, wonach der Dienst entfernt wird und die Hardware für andere Dienste bereitgestellt wird. Der Dienstendpunkt wird aus dem Verzeichnis entfernt, wenn das Verzeichnis feststellt, dass der Dienstendpunkt von dem Dienstanbieter entfernt wurde.
Ein Verzeichnis wird von Administratoren verwendet, die die Dienste direkt oder unter Verwendung von SOA-Verwaltungsanwendungen bereitstellen. Werden Dienste von einem Administrator gestartet, werden Endpunktinformationen für ihre Nutzung durch Administratoren oder SOA-Verwaltungsanwendungen automatisch in das Verzeichnis gestellt. Die Endpunktinformationen enthalten andere Arten von Endpunkten sowie Dienstendpunkte, und die Erfindung erkennt, dass bei Fehlen eines Dienstendpunkts ein neuer Dienstendpunkt unter Verwendung der anderen Arten von Endpunktinformationen angefordert oder bereitgestellt werden kann. Andere Arten von Endpunkten sind abstrakter als Dienstendpunkte, bei denen es sich allgemein um Internetprotokolladressen handelt. Die Ausführungsformen stellen Administratoren und/oder Verwaltungsanwendungen die anderen Arten von Endpunktinformationen zur Verfügung.
Die Erfindung umfasst u.a. ein Dienstverzeichnis. Das Verzeichnis weist eine Dereferenzierungsschicht auf, wobei die aufrufende Anwendung nicht notwendigerweise die Position des Dienstendpunkts kennt. Die Dereferenzierung wird von Dienstanwendungen auf einem Enterprise Service Bus (ESB) verwendet, um die Richtung von zu verschiedenen Endpunkten laufenden Dienstanforderungen abhängig von Diensteigenschaften wie beispielsweise Qualität des Dienstes oder Lastverteilung verwalten zu können.
Wenn kein geeigneter Dienstendpunkt vorhanden ist oder die Leistungsmerkmale zu niedrig sind, dann wird eine Anforderung zum Bereitstellen einer neuen Instanz des Dienstes gestellt. Ein Beispiel eines vorhandenen Endpunkts, bei dem es sich nicht um einen Dienstendpunkt handelt, ist ein Cloud-Werkzeug, das auf Anforderung virtuelle Maschinenabbilder bereitstellt.
Ist kein Dienstendpunkt vorhanden, kann das Verzeichnis warten, bis eine neue Dienstendpunktinstanz bereitgestellt wurde. Das Dienstverzeichnis sendet diesen neuen Dienstendpunkt zu der anfordernden Anwendung zurück, und die Anforderung wird zu dem neuen Dienstendpunkt geleitet. Wenn bereits Dienstendpunkte zur Verfügung stehen, kann die Anforderung zu den vorhandenen Dienstendpunkten geleitet werden, wenn der neue Dienstendpunkt jedoch bereitgestellt wird, steht künftigen Anforderungen neben den vorhandenen Dienstendpunkten auch der neue Dienstendpunkt zur Verfügung.
Ein Vorteil der Erfindung besteht darin, dass Dienste mit geringer Nachfrage unter den zur Verfügung stehenden Diensten eines Dienstanbieters besser verwaltet werden können, da die Erfindung einen Dienst wirksamer deinstallieren und anschließend wieder neu installieren kann. Implementierte Dienstinstanzen können so überwacht werden, dass das virtuelle Maschinenabbild des Dienstes von dem Cloud-Server entfernt wird, wenn die Nutzung des Dienstes unter ein festgelegtes Niveau fällt oder ein Zeitlimit erreicht wird.
Die Erfindung ist besonders für einen Dienstanbieter von Vorteil, der über eine begrenzte Anzahl von Servern verfügt und Kunden viele Dienste anbieten möchte, indem er Cloud-Ressourcen zur Erweiterung der Dienste verwendet. Ein solcher Dienstanbieter kann virtuelle Endpunkte bereitstellen, die eine beliebige Anzahl von Diensten aufnehmen können. Der Dienstanbieter würde einfach einen neuen Dienst bereitstellen, wenn eine Dienstanforderung empfangen wird, und den Dienst entfernen, wenn der Nutzungsgrad zurückgegangen ist. Dies würde bedeuten, dass der Dienstanbieter nur dann für die Nutzung der Cloud zu zahlen hat, wenn diese zum Aufnehmen von Diensten verwendet wird, wodurch sichergestellt wird, dass die Server-Kosten keine Fixkosten sind.
Figurenliste
Im Folgenden werden Ausführungsformen der Erfindung mit Bezug auf die beigefügten Zeichnungen beschrieben, in denen:

1 ein Komponentenschaubild eines Computersystemknotens nach dem Stand der Technik ist;
2 ein Komponentenschaubild einer Computernetzwerkumgebung mit mehr als einem Computersystemknoten nach dem Stand der Technik ist;
3 ein Komponentenschaubild eines SOA-Systems ist, das die Interaktionen zwischen einem Dienstverzeichnis, einem Dienstanforderer und Dienstanbietern gemäß einer bevorzugten Ausführungsform der Erfindung zeigt;
4 ein Komponentenschaubild eines SOA-Systems ist, das die Interaktionen zwischen einem Dienstverzeichnis, einem Dienstanforderer, Dienstanbietern und einem Ressourcenanbieter gemäß einer Ausführungsform der Erfindung für einen Ressourcenanbieter zeigt;
5 ein Komponentenschaubild eines Dienstverzeichnisses gemäß Ausführungsformen der Erfindung ist;
6 Virtualisierungsschichten gemäß einer Ausführungsform der vorliegenden Erfindung für eine Cloud zeigt;
7 ein Prozessschaubild eines Verfahrens der bevorzugten Ausführungsform der Erfindung ist;
8 ein Prozessschaubild eines Durchführungsverfahrens der bevorzugten Ausführungsform der Erfindung ist; und
9 ein Prozessschaubild ist, das ein zusätzliches Verfahren der bevorzugten Ausführungsform der Erfindung zum Durchsuchen eines Verzeichnisses zeigt.

BESCHREIBUNG DER AUSFÜHRUNGSFORMEN
Unter Bezugnahme auf 1 ist ein Komponentenschaubild eines Computersystemknotens 10 nach dem Stand der Technik dargestellt. Der Computersystemknoten 10 weist ein Computersystem/einen Server 12 auf, das/der mit zahlreichen anderen Universal- oder Spezialcomputersystemumgebungen oder konfigurationen funktionsfähig ist. Zu Beispielen bekannter Computersysteme, Umgebungen und/oder Konfigurationen, die für die Verwendung mit dem Computersystem/Server 12 geeignet sein können, gehören, ohne darauf beschränkt zu sein, Personal-Computer-Systeme, Server-Computer-Systeme, Thin Clients, Thick Clients, tragbare oder Laptop-Einheiten, Multiprozessorsysteme, Systeme auf Mikroprozessorbasis, Set Top Boxes, programmierbare Unterhaltungselektronik, Netzwerk-PCs, Minicomputersysteme, Großrechnersysteme und verteilte Cloud-Computing-Umgebungen, die beliebige der oben genannten Systeme oder Einheiten und Ähnliches beinhalten.
Das Computersystem/der Server 12 kann im allgemeinen Kontext von Befehlen beschrieben werden, die auf einem Computersystem ausgeführt werden können, so wie beispielsweise Programmmodule, die von einem Computersystem ausgeführt werden. Zu Programmmodulen allgemein können Routinen, Programme, Objekte, Komponenten, Logiken, Datenstrukturen usw. gehören, die bestimmte Aufgaben durchführen oder bestimmte abstrakte Datenarten implementieren.
Das Computersystem/der Server 12 kann in verteilten Cloud-Computing-Umgebungen umgesetzt werden, wo Aufgaben von Fernverarbeitungseinheiten durchgeführt werden, die über ein Datenübertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl in lokalen als auch rechnerfernen Speichermedien eines Computersystems befinden, zu denen Speichereinheiten gehören.
Wie in 1 gezeigt, ist das Computersystem/der Server 12 im Computersystemknoten 10 in Form einer Universalrechnereinheit dargestellt. Zu den Komponenten des Computersystems/Servers 12 können ein oder mehrere Prozessoren oder Verarbeitungseinheiten 16, ein Systemspeicher 28 und ein Bus 18 gehören, ohne darauf beschränkt zu sein, wobei der Bus verschiedene Systemkomponenten verbindet, darunter den Systemspeicher 28 mit dem Prozessor 16.
Der Bus 18 stellt eine oder mehrere beliebige Arten von Busstrukturen dar, darunter ein Speicherbus oder Speichercontroller, ein peripherer Bus, ein Accelerated Graphics Port (beschleunigter Grafikanschluss) und ein Prozessor oder lokaler Bus, der eine beliebige Busarchitektur aus einer Vielfalt von Busarchitekturen verwendet.
Zu solchen Architekturen gehören zum Beispiel, ohne beschränkend zu sein, der Industry-Standard-Architecture(ISA)-Bus, der Micro-Channel-Architecture(MCA)-Bus, der Enhanced-ISA(EISA)-Bus, der Video-Electronics-Standards-Association(VESA)-Bus und der Peripheral-Component-Interconnects(PCI)-Bus.
Das Computersystem/der Server 12 weist üblicherweise eine Vielfalt von Medien auf, die von einem Computersystem gelesen werden können. Bei solchen Medien kann es sich um beliebige Medien handeln, auf die von dem Computersystem/Server 12 zugegriffen werden kann, und die flüchtige und nichtflüchtige Medien, austauschbare und nicht austauschbare Medien enthalten können.
Der Systemspeicher 28 kann vom Computersystem lesbare Medien in Form eines flüchtigen Speichers wie beispielsweise eines Direktzugriffsspeichers (RAM) 30 und/oder Cachespeichers 32 beinhalten. Das Computersystem/der Server 12 kann weiterhin andere austauschbare/nicht austauschbare, flüchtige/nichtflüchtige Speichermedien eines Computersystems enthalten. Das Speichersystem 34 kann nur als Beispiel zum Lesen von nicht austauschbaren, nichtflüchtigen magnetischen Medien (nicht dargestellt und üblicherweise als „Festplatte“ bezeichnet) und zum Schreiben auf dieselben bereitgestellt werden. Obgleich dies nicht dargestellt ist, kann ein Magnetplattenlaufwerk zum Lesen von einer austauschbaren, nichtflüchtigen Magnetplatte (z.B. einer „Diskette“) und zum Schreiben auf dieselbe und ein optisches Plattenlaufwerk zum Lesen von einer austauschbaren, nichtflüchtigen optischen Platte oder zum Schreiben auf dieselbe, beispielsweise eine CD-ROM, DVD-ROM oder andere optische Medien, bereitgestellt werden. In solchen Fällen können diese jeweils über eine oder mehrere Datenträgerschnittstellen mit dem Bus 18 verbunden sein. Wie nachstehend genauer dargestellt und beschrieben wird, kann der Speicher 28 mindestens ein Programmprodukt mit einem Satz von Programmmodulen (z.B. mindestens eines) beinhalten, die konfiguriert sind, um die Funktionen von Ausführungsformen der Erfindung durchzuführen.
Das Programm/Dienstprogramm 40, das einen Satz von Programmmodulen 42 (z.B. mindestens eines) aufweist, kann zum Beispiel, ohne beschränkend zu sein, in dem Speicher 28 gespeichert werden, ebenso wie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten. Das Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten oder eine Kombination davon können jeweils eine Ausführung einer Netzwerkumgebung aufweisen. Die Programmmodule 42 führen allgemein die Funktionen und/oder Methodologien von Ausführungsformen der Erfindung wie hier beschrieben durch.
Das Computersystem/der Server 12 kann auch mit einer oder mehreren externen Einheiten 14 wie beispielsweise einer Tastatur, einem Zeigegerät, einer Anzeige 24 usw. Daten austauschen sowie mit einer oder mehreren Einheiten, die es einem Benutzer ermöglichen, mit dem Computersystem/Server 12 zu interagieren, und/oder mit beliebigen Einheiten (z.B. Netzwerkkarte, Modem usw.), die es dem Computersystem/Server 12 ermöglichen, mit einer oder mehreren anderen Rechnereinheiten Daten auszutauschen. Ein solcher Datenaustausch kann über die E/A-Schnittstellen 22 stattfinden. Das Computersystem/der Server 12 kann des Weiteren noch über den Netzwerkadapter 20 mit einem oder mehreren Netzwerken wie beispielsweise einem lokalen Netzwerk (LAN), einem allgemeinen Weitverkehrsnetzwerk (WAN) und/oder einem öffentlichen Netzwerk (z.B. das Internet) Daten austauschen. Wie dargestellt, tauscht der Netzwerkadapter 20 über den Bus 18 mit den anderen Komponenten des Computersystems/Servers 12 Daten aus. Es versteht sich, dass andere Hardware- und/oder Software-Komponenten, obgleich nicht dargestellt, in Verbindung mit dem Computersystem/Server 12 verwendet werden können. Zu den Beispielen gehören, ohne darauf beschränkt zu sein: Mikrocode, Einheitentreiber, redundante Verarbeitungseinheiten, externe Plattenlaufwerkstapel, RAID-Systeme, Bandlaufwerke und Speichersysteme für die Datenarchivierung.
Unter Bezugnahme auf 2 nunmehr ist eine veranschaulichende Cloud-Computing-Umgebung 50 nach dem Stand der Technik dargestellt. Die Cloud-Computing-Umgebung 50 weist wie dargestellt einen oder mehrere Cloud-Rechnerknoten 10 auf, mit denen lokale Rechnereinheiten, die von Cloud-Nutzern wie beispielsweise einem persönlichen digitalen Assistenten (PDA) oder Mobiltelefon 54A, einem Desktop-Computer 54B, einem Laptop-Computer 54C und/oder einem Automobil-Computersystem 54N genutzt werden, Daten austauschen können. Die Knoten 10 können untereinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken wie beispielsweise in privaten, Community-, öffentlichen oder hybriden Clouds oder einer Kombination davon zusammengefasst werden (nicht dargestellt). Die Cloud-Computing-Umgebung 50 kann auf diese Weise Infrastruktur, Plattformen und/oder Software als Dienste anbieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Rechnereinheit bereithalten muss. Es versteht sich, dass die in 2 dargestellten Arten von Rechnereinheiten 54A bis N nur zur Veranschaulichung dienen sollen und dass die Rechnerknoten 10 und die Cloud-Computing-Umgebung 50 mit jeder beliebigen Art von computergestützter Einheit über jede beliebige Art von Netzwerk und/oder einer netzwerkadressierbaren Verbindung (z.B. unter Verwendung eines Webbrowser) Daten austauschen können.
Unter Bezugnahme auf 3 ist ein Komponentenschaubild eines SOA-Systems 300 gemäß einer bevorzugten Ausführungsform der Erfindung dargestellt, wobei das SOA-System 300 eine Benutzereinheit 54A und mindestens zwei Netzwerke 301 und 306 aufweist. Das erste Netzwerk 301 weist mindestens einen Dienstanbieter 302 und ein Verzeichnis 304 auf, wobei das erste Netzwerk 301 üblicherweise ein Unternehmensnetzwerk ist. Der Dienstanbieter 302 weist einen beispielhaften Abbildungs- und Navigationsdienst 310 auf. Ein zweites Netzwerk 306 weist die Dienstanbieter 308A bis N auf. Das Verzeichnis 304 beinhaltet eine Dienstendpunkt-Steuerkomponente 532.
Eine bekannte Interaktion zwischen einer Client-Einheit 54A und einem Dienstanbieter 302 oder 308A bis N läuft wie folgt ab. Die Client-Einheit 54A fordert die Nutzung eines Dienstes von dem Verzeichnis 304 an, zum Beispiel kann die Client-Einheit eine Abbildung ihres Standorts anfordern. Das Verzeichnis 304 sucht und findet den angeforderten Dienst, zum Beispiel den Abbildungs- und Navigationsdienst 310. Das Verzeichnis wählt anschließend einen oder mehrere Dienstendpunkte aus, die dem lokalisierten Dienst zugeordnet sind. Jeder Dienstendpunkt weist mindestens eine Internet-Protokoll(IP)-Adresse auf und optional eine Anschlussnummer und den Namen eines Dienstanbieters, um eine IP-Dienstanforderung an den Dienstanbieter zu ermöglichen. Das Verzeichnis 304 sendet den Dienstendpunkt anschließend an die anfordernde Client-Einheit 54A zurück, und die Client-Einheit 54A fordert unter Verwendung eines oder mehrerer der bereitgestellten Dienstendpunkte den Abbildungsdienst von dem Dienstanbieter 302 oder 308A bis N an. Das Verzeichnis 304 kann einen Dienstendpunkt bereitstellen, der sich in der gleichen Domäne oder dem gleichen Unternehmen (das heißt dem ersten Netzwerk 301) wie das Verzeichnis 304 befindet, oder es kann einen Endpunkt bereitstellen, der sich in einer anderen Domäne oder einem anderen Unternehmen befindet. Der Client kann mit dem bereitgestellten Dienstendpunkt unabhängig einen Dienst von einem Dienstanbieter anfordern.
Ein Problem tritt dann auf, wenn das Verzeichnis 304 keinen geeigneten Dienstendpunkt für eine Dienstanforderung finden kann. Alle Ausführungsformen stellen eine Dienstendpunkt-Steuerkomponente 532 als Teil des Verzeichnisses bereit, um einen geeigneten Dienstendpunkt außerhalb des Verzeichnisses zu suchen, wenn kein Endpunkt im Verzeichnis gefunden wird. Alle Ausführungsformen suchen den Dienstendpunkt von Dienstanbietern und auch anderen Dienstverzeichnissen (andere Dienstverzeichnisse sind in den 3 und 4 nicht dargestellt). Wenn ein Dienstendpunkt nicht im Verzeichnis 304 vorhanden ist, kann das Verzeichnis 304 durch den Datenaustausch mit anderen Dienstentitäten feststellen, ob der Dienst vorübergehend offline ist oder nicht mehr von einem Dienstanbieter bereitgestellt wird. Bei einem Dienst, der vorübergehend offline ist, handelt es sich um einen Dienst, bei dem ein Dienstendpunkt fehlt oder der nicht installiert ist. Wenn der Dienst vorübergehend offline ist, dann versucht das Verzeichnis 304, den Dienst beim Dienstanbieter wieder als verfügbar herzustellen. Sobald ein Dienstanbieter 302 oder 308A bis N einen Dienstendpunkt für einen bestimmten Dienst zur Verfügung stellt, wird der neu bereitgestellte Dienstendpunkt zum ersten Mal im Dienstverzeichnis registriert oder von dem Verzeichnis 304 neu registriert und anschließend dem Dienstanforderer 54A wieder bereitgestellt. Bei der bevorzugten Ausführungsform tauscht der Dienstanforderer 54A unter Verwendung des bereitgestellten Endpunkts direkt mit dem Dienstanforderer Daten aus.
Unter Bezugnahme auf 4 ist ein SOA-System 400 dargestellt, das eine vollständige Dienstverwaltung gemäß einer Ausführungsform der Erfindung für eine Dienstverwaltung bereitstellt. Das SOA-System 400 weist eine Benutzereinheit 54A und mindestens zwei Netzwerke 401 und 406 auf. Das erste Netzwerk 401 weist mindestens einen Dienstanbieter 402, ein Verzeichnis 404 und einen Ressourcenanbieter 405 auf, wobei das erste Netzwerk 401 üblicherweise ein Unternehmensnetzwerk ist. Ein zweites Netzwerk 406 weist Dienstanbieter 408A bis N auf. Das Verzeichnis 404 enthält eine Dienstendpunkt-Steuerkomponente 532. Der Dienstanbieter 402 weist einen beispielhaften Abbildungs- und Navigationsdienst 410 auf.
Bei dieser Ausführungsform weist die vollständige Dienstverwaltung ein Verzeichnis 404 auf, das mit dem Ressourcenanbieter 405 interagiert, um einen Dienst bereitzustellen, zum Beispiel einen Abbildungsdienst, ohne dass ein Client einen Dienstanbieter beauftragen muss. Ein Client fordert den Dienst von dem Dienstverzeichnis an, und anschließend stellt der Ressourcenanbieter den Dienst von dem Dienstanbieter bereit. Sobald ein neu festgestellter Dienstendpunkt registriert ist, wird dieser von dem Ressourcenanbieter 405 verwendet, um mit dem Dienstanbieter 402 oder 408A bis N zum Steuern des Dienstes zu interagieren. Der Ressourcenanbieter 405 fungiert als Vermittler (proxy), um zwischen dem Dienstanbieter 402 oder 408A bis N und dem Dienstanforderer 54A Daten auszutauschen. Der Ressourcenanbieter 405 ermöglicht die vollständige Dienstverwaltung des Dienstes, einschließlich: Inrechnungstellen des Dienstes und Verwaltung der Dienstqualität. Bei dieser Ausführungsform tauscht der Dienstanforderer 54A nicht direkt mit dem Dienstanbieter 405 Daten aus, und der Dienstanforderer 54A kennt die eigentliche Endpunktadresse des Dienstanbieters 402 oder 408A bis N nicht.
Unter Bezugnahme auf 5 wird ein Komponentenschaubild eines Dienstverzeichnisses 304 (oder 404) gemäß den Ausführungsformen der Erfindung beschrieben. Ein Dienstverzeichnis 304 oder 404 speichert eine Vielzahl von Dienstdokumenten und ermöglicht den Zugriff auf die Dokumente und die entsprechenden Dienste. Die Dienstdokumente sind indexiert, und die Indizes sind in einem Dienstverzeichnis gespeichert, um ein Lokalisieren eines spezifischen Dienstes mit einer bestimmten Eigenschaft zu ermöglichen. Das Dienstverzeichnis ist ein Index einer Teilmenge von Informationen über einen Dienst (zum Beispiel Speicherort und Name des Dienstdokuments), dadurch kann das entsprechende Dienstdokument lokalisiert und in einem Repository 514 darauf zugegriffen werden (oder sogar der entsprechende Dienst beim Dienstanbieter). Über ein eng verbundenes Dienstverzeichnis und Repository kann eine Dienstoperation die indexierten Dienstinformationen in dem Verzeichnis und auch die detaillierten Dienstinformationen in dem Repository verwenden. Ein Beispiel eines integrierten Dienstverzeichnisses und Repository ist das WebSphere* Registry and Repository (WSRR) von IBM.
Ein solches integriertes Dienstverzeichnis und Repository hat den Vorteil, dass die Beweglichkeit der Geschäftsabläufe und die Hochverfügbarkeit und Ausfallsicherheit von Geschäftsanwendungen und -prozessen durch die Wiederverwendung besser sind als bei separaten Systemen. Aus der Integration ergeben sich noch weitere Vorteile wie lockerere Verbindung, größere Flexibilität, bessere Interoperabilität und bessere Regulierung. Diese Vorteile werden sichergestellt, indem die Dienstbeschreibungen von ihren Implementierungen getrennt werden und indem die Dienstbeschreibungen im gesamten Lebenszyklus des Dienstes verwendet werden. Standardbasierte Dienst-Metadatenartefakte wie beispielsweise die Web Service Definition Language (WSDL), das Schema der Extensible Mark-up Language (XML), Richtlinien- oder Service-Component-Architecture(SCA)-Dokumente erfassen die technischen Einzelheiten im Hinblick darauf, was ein Dienst machen kann, wie dieser aufgerufen werden kann oder was er von anderen Diensten erwartet. Diesen Artefakten können semantische Anmerkungen und andere Metadaten zugeordnet werden, um potenziellen Nutzern einen Überblick darüber zu verschaffen, wie und wann der Dienst genutzt werden kann und welchen Zwecken er dient.
Die bevorzugte Ausführungsform ist ein Dienstverzeichnis und Repository für Dienstdokumente auf der Grundlage des WebSphere Service Registry and Repository von IBM. Solche Dienstdokumente enthalten herkömmliche Internet-Dienste, die eine Reihe von Protokollen verwenden und gemäß einer Vielfalt von Programmiermodulen implementiert werden. Obgleich die bevorzugte Ausführungsform ein unabhängiges Dienstverzeichnis ist, können Ausführungsformen andere SOA-Komponenten mit integriertem Dienstverzeichnis aufweisen; zum Beispiel kann ein Dienstanbieter über ein integriertes Dienstverzeichnis verfügen, um Verzeichnisfunktionen sowie Dienstanbieterfunktionen zu ermöglichen.
Das Dienstverzeichnis 304 (oder 404) der bevorzugten Ausführungsform ist eine Java*-Plattform, eine Enterprise-Edition(Java EE 6)-Anwendung, die auf einem WebSphere-Anwendungsserver 7 von IBM läuft und eine Objektdatenbank als Sicherungsspeicher zum Speichern der Dienstmetadaten verwendet. Das Dienstverzeichnis nutzt die rollenbasierte Zugriffssteuerung, so dass rollenbasierte Ansichten und die Zugriffssteuerung aktiviert werden können, wenn das Dienstverzeichnis und das Repository als eine unternehmensweite Anwendung implementiert werden. Unter Bezugnahme auf 5 weist das Dienstverzeichnis 304/404 auf: eine Verzeichnis-Steuerkomponente 512, ein Repository 514, einen Governor 520, ein Klassifizierungsmerkmal 522, einen Zugriffscontroller 524, eine Verwaltungsschnittstelle 526, eine Benutzerschnittstelle 528, eine Programmierschnittstelle 530 und eine Dienstendpunkt-Steuerkomponente 532.
Die Verzeichnis-Steuerkomponente 512 bietet sowohl eine Verzeichnisfunktion als auch eine Repository-Funktion für Dienstmetadaten. Die Repository-Funktion ermöglicht es Benutzern, Dienst-Metadatenartefakte mit Dienstbeschreibungen zu speichern (im Repository 514), zu verwalten und abzufragen. Die Verzeichnis-Steuerkomponente 512 verwaltet nicht nur die Dokumente mit den Dienstmetadaten durch eine zuverlässige Datenspeicherung, sondern stellt auch eine detaillierte Darstellung des Inhalts dieser Dokumente bereit, in einigen Dienstdokumenten zum Beispiel die Anschlüsse und Anschlussarten. Die Verzeichnis-Steuerkomponente 512 stellt sicher, dass registrierte Diensterklärungen und Elemente der abgeleiteten Inhaltsmodelle mit benutzerdefinierten Eigenschaften, Beziehungen und Klassifizierungen dekoriert werden. Das Verzeichnis stellt eine Benutzerschnittstelle 528 bereit, die diese Dekorationen verwendet, wenn eine Suche durchgeführt wird, um Entitäten wie beispielsweise einen Dienstendpunkt oder eine Dienstschnittstelle zu finden.
Im Repository 514 gespeicherte Dokumente werden von der Verzeichnis-Steuerkomponente 512 in Bezug auf Änderungen überwacht. Sobald die Verzeichnis-Steuerkomponente 512 eine Änderung an dem Dienstdokument feststellt, ruft sie Gültigkeitsprüfungs- und Benachrichtigungsfunktionen auf. Beide Funktionsarten werden als Erweiterungsmechanismen angesehen, die verwendet werden können, um die Reaktion der Verzeichnis-Steuerkomponente 512 auf Änderungen anzupassen. Die Gültigkeitsprüfungsfunktion kann so geschrieben werden, dass die Verzeichnis-Steuerkomponente 512 ausgeführt wird, sobald Änderungen am Inhalt vorgenommen werden. Zum Beispiel eine Gültigkeitsprüfungsfunktion, die die Vollständigkeit einer Dienstdefinition prüft. Die Verzeichnis-Steuerkomponente 512 enthält ein Benachrichtigungs-Plug-in (nicht dargestellt) mit einer Subskriptionsfunktion für eine Benachrichtigung, die eine Änderung des Inhalts von Dienstverzeichnis und Repository mitteilt.
Die Verzeichnis-Steuerkomponente 512 unterstützt über den Governor 520 eine große Menge an erweiterbaren Regulierungsfunktionen, darunter die Fähigkeit, einen Dienstlebenszyklus für eine regulierte Entität zu modellieren, gültige Übergänge zwischen Dienstzuständen zu definieren, Validatoren zu schreiben und einzusetzen, um die Übergänge zwischen den Zuständen zu schützen, und Maßnahmen (Benachrichtigungsmaßnahmen) zu bestimmen, die als Reaktion auf den Übergang getroffen werden. Der Governor 520 stellt Schnittstellen bereit, um die Auswirkungen der Änderungen auf den Inhalt zu analysieren, und gewährleistet ein Überprüfen dieser Änderungen.
Das Klassifizierungsmerkmal 522 ermöglicht es, dass Dienstbeschreibungen und Teile von Dienstdefinitionen mit Unternehmensvokabular versehen werden und den Regulierungszustand erfassen. Dienstklassifizierungssysteme werden in Dokumenten in Web Ontology Language (OWL) erfasst, die unter Verwendung der Verwaltungsschnittstelle 526 in das Dienstverzeichnis geladen werden. Dienstverzeichnisentitäten können mit Werten von diesen Klassifizierungssystemen klassifiziert werden, so dass klassifizierungsbasierte Abfragen durchgeführt werden können und Zugriffsbeschränkungen auf der Grundlage einer Klassifizierung möglich sind.
Der Zugriffscontroller 524 unterstützt ein detailliertes Zugriffssteuerungsmodell, das eine Definition im Hinblick darauf ermöglicht, welche Benutzerrollen spezifische Arten von Maßnahmen bei entsprechenden Artefakten durchführen können. Die Sichtbarkeit der Dienste kann durch den Unternehmensbereich eingeschränkt sein, und das Überleiten von Diensten in bestimmte Lebenszykluszustände kann für Benutzerrollen beschränkt sein. Dies wird neben der rollenbasierten Zugriffssteuerung von dem Dienstverzeichnis und dem Repository bereitgestellt.
Die Verwaltungsschnittstelle 526 unterstützt den Import und Export des Repository-Inhalts, um diesen mit anderen Repositorys auszutauschen, und stellt eine Anwendungsprogrammierschnittstelle (application programming interface, API) für die Konfiguration und grundlegende Verwaltung bereit. Diese unterstützen Interaktionen mit dem Zugriffscontroller 524 und dem Klassifizierungsmerkmal 522.
Die Benutzerschnittstelle 528 ermöglicht eine Interaktion des Benutzers mit dem Dienstverzeichnis und dem Repository und unterstützt alle Benutzerrollen, bietet Such-, Browser-, Lese-, Veröffentlichungs- und Anmerkungsfunktionen an sowie Regulierungsaktivitäten wie Import/Export und Auswirkungsanalyse. Die Benutzerschnittstelle kann als Plug-in für verschiedene Tools von anderen Anbietern angeboten werden, um eine Interoperabilität zu unterstützen.
Die Programmierschnittstelle 530 verwendet Standard-APIs, um mit der Verzeichnis-Steuerkomponente 512 zu interagieren (zum Beispiel Java und ein Standard-SOA-Protokoll). Die Programmierschnittstelle 530 stellt Schnittstellen für grundlegende Operationen wie Anlegen, Lesen, Aktualisieren und Löschen (create, retrieve, update, delete, CRUD) sowie Regulierungsoperationen und eine flexible Abfragefunktion bereit. Die Programmierschnittstelle 530 kann unter Verwendung von XML-Datenstrukturen oder Service Data Objects (SDOs) Inhalt weiterleiten. Dokumente können entweder unter Verwendung der Benutzerschnittstelle 528 oder der Programmierschnittstelle 530 angelegt, gelesen, aktualisiert und gelöscht werden.
Die Dienstendpunkt-Steuerkomponente 532 weist eine Verarbeitungslogik zum Bearbeiten von Anforderungen für Dienstendpunkte auf. Die Verarbeitungslogik bearbeitet die Anforderung, wenn kein Dienstendpunkt vorhanden ist oder wenn die Qualität des angeforderten Dienstes nicht mit der Qualität des von einem Dienstendpunkt bereitgestellten Dienstes übereinstimmt. Die von der Dienstendpunkt-Steuerkomponente 532 durchgeführten Prozessschritte werden mit Bezug auf Ausführungsformen der 7, 8 und 9 beschrieben.
Unter Bezugnahme auf 6 werden im Folgenden Schichten eines Virtualisierungsabstraktionsmodells beschrieben, die von einer Cloud-Computing-Umgebung der bevorzugten Ausführungsform der vorliegenden Erfindung bereitgestellt werden. Die in 6 dargestellten Komponenten, Schichten und Funktionen sollen nur zur Veranschaulichung dienen, und die Ausführungsformen der Erfindung sind nicht darauf beschränkt. Folgende Schichten und entsprechende Funktionen werden wie dargestellt bereitgestellt: eine Hardware- und Software-Schicht 60; eine Virtualisierungsschicht 62; eine Verwaltungsschicht 64 und eine Workload-Schicht 66.
Die Hardware- und Software-Schicht 60 beinhaltet Hardware- und Software-Komponenten. Zu Beispielen von Hardware-Komponenten gehören Großrechner, in einem Beispiel die zSeries*-Systeme von IBM, auf RISC-Architektur (RISC = Reduced Instruction Set Computer, Computer mit reduziertem Befehlssatz) beruhende Server, in einem Beispiel die pSeries*-Systeme von IBM, die xSeries*-Systeme von IBM, die BladeCenter*-Systeme von IBM, Speichereinheiten, Netzwerke und Netzwerkkomponenten. Zu Beispielen von Software-Komponenten gehören Server-Software für Netzwerkanwendung, in einem Beispiel die Anwendungsserversoftware WebSphere von IBM, und Datenbank-Software, in einem Beispiel die Datenbank-Software DB2* von IBM.
Die Virtualisierungsschicht 62 stellt eine Abstraktionsschicht bereit, von der die folgenden Beispiele von virtuellen Entitäten bereitgestellt werden können: virtuelle Server; virtuelle Speicher; virtuelle Netzwerke, darunter virtuelle private Netzwerke; virtuelle Anwendungs- und Betriebssysteme; und virtuelle Clients.
Bei der bevorzugten Ausführungsform sind das Dienstverzeichnis 304 und die Ressourcenbereitstellung Teil der Verwaltungsschicht 64 eines Cloud-Systems. Die Verwaltungsschicht 64 beinhaltet weitere Funktionen wie beispielsweise Messung und Preisbestimmung, Benutzerportale und das Dienstgütemanagement (service level management). Die Ressourcenbereitstellung gewährleistet eine dynamische Bereitstellung von Rechnerressourcen und anderen Ressourcen, die zum Durchführen von Aufgaben in der Cloud-Computing-Umgebung verwendet werden. Das Dienstverzeichnis stellt das Verzeichnis für die im Cloud-System verwendeten Rechnerressourcen und anderen Ressourcen bereit. Messung und Preisbestimmung stellen eine Kostenverfolgung bereit, wenn Ressourcen in der Cloud-Computing-Umgebung verwendet werden, sowie Inrechnungstellung oder Fakturierung für die Nutzung dieser Ressourcen. In einem Beispiel können diese Ressourcen Lizenzen für Anwendungssoftware aufweisen. Ein Benutzerportal stellt den Zugriff auf die Cloud-Computing-Umgebung für Nutzer und Systemadministratoren bereit. Das Dienstgütemanagement stellt die Zuweisung und Verwaltung der Cloud-Computing-Ressource bereit, um sicherzustellen, dass die erforderliche Dienstgüte eingehalten wird.
Die Workload-Schicht 66 stellt Funktionalitätsbeispiele bereit, für die die Cloud-Computing-Umgebung verwendet werden kann. Zu Beispielen von Workloads und Funktionen, die von dieser Schicht bereitgestellt werden können, gehören: Abbildung und Navigation, Software-Entwicklung und Lebenszyklusmanagement, Bereitstellung von virtueller Schulung, Datenanalyseverarbeitung, Transaktionsverarbeitung und mobiler Desktop. Bei einem SOA-System sind die Workloads in der Workload-Schicht als Dienste implementiert.
Unter Bezugnahme auf 7 folgt eine Beschreibung eines Prozesses der bevorzugten Ausführungsform, der von der Verarbeitungslogik der Dienstendpunkt-Steuerkomponente 532 und dazugehörigen Komponenten in dem SOA-System 300 oder 400 durchgeführt wird. Dieser Prozess kann für die Ausführungsform in Bezug auf eine mindestens vollständige Dienst-Ressourcenbereitstellung mit geeigneten Änderungen angepasst werden. Der Prozess wird als Prozessschritte im Zusammenhang mit den Hauptkomponenten des SOA-Systems und insbesondere im Zusammenhang mit einem Dienstverzeichnis beschrieben.
Der Dienstanforderer 54A fordert in Schritt 702 von einem Dienstanbieter einen Dienst an und leitet die Anforderung an das Dienstverzeichnis 304 weiter. Zum Beispiel einen der Dienste der Workload 66 (vgl. 6).
Das Dienstverzeichnis 304 durchsucht in Schritt 704 das Repository 514 nach einem Dienstendpunkt, der der Dienstanforderung zugeordnet ist, wobei das Dienstverzeichnis nach dem bei dieser Ausführungsform behandelten Problem keinen zugeordneten Dienstendpunkt findet.
Im Verzeichnis wird kein genauer Dienstendpunkt lokalisiert, Dienstinformationen, die dem angeforderten Dienst zugeordnet sind, werden jedoch in Schritt 706 verwendet, um einen Dienstanbieter zu lokalisieren. Wenn keine zugeordneten Dienstinformationen vorhanden sind, wird ein Standarddienstanbieter lokalisiert. Ein Name eines Dienstanbieters oder generische Verwaltungsinformationen zu Endpunkten können im Repository gespeichert und der Dienstanforderung zugeordnet werden. In Schritt 706 wird auf alle Fälle ein Dienstanbieter lokalisiert oder bereitgestellt.
In Schritt 708 wird ein Dienstendpunkt für den angeforderten Dienst von dem lokalisierten oder Standarddienstanbieter angefordert.
Der lokalisierte oder Standarddienstanbieter 308N empfängt in Schritt 710 die Dienstanforderung und richtet den Dienst in Schritt 712 ein. Sobald der Dienst eingerichtet ist, ordnet der Dienstanbieter den eingerichteten Dienst einem Dienstendpunkt zu. Der Dienst kann bereits eingerichtet sein und einen bestehenden Dienstendpunkt aufweisen, was dem Dienstverzeichnis nicht bekannt ist. Der Dienst kann ohne einen Dienstendpunkt eingerichtet worden sein, daher richtet der Dienstanbieter nur ein und ordnet einen Dienstendpunkt zu. Wenn der Dienst nicht eingerichtet wurde, dann richtet ihn der Dienstanbieter entweder an einem bekannten Ort oder virtuell an einem unbekannten Ort ein. Für eine virtuelle Einrichtung richtet die Ressourcenbereitstellung in der Verwaltungsschicht 64 eine erforderliche Virtualisierungsschichtkonfiguration von Servern, Speichern, Netzwerken, Anwendungen und Clients und der Workload 66 ein.
Der Dienstendpunkt wird unabhängig davon, ob er zuvor vorhanden war oder nicht, in Schritt 714 an das Verzeichnis 304 zurückgesendet.
Das Verzeichnis ordnet anschließend in Schritt 716 den im Dienstverzeichnis registrierten Dienst dem empfangenen Dienstendpunkt zu.
Das Verzeichnis sendet dann den empfangenen Dienstendpunkt in Schritt 718 an den Dienstanforderer 54A.
Bei dieser bevorzugten Ausführungsform fordert der Dienstanforderer 54A den Dienst von dem Dienstanbieter 302N am empfangenen Dienstendpunkt an.
Der Dienstanbieter empfängt die Dienstanforderung am Dienstendpunkt und beginnt, den Dienst in Schritt 722 wieder zurück an den Dienstanforderer 54A zu senden.
Der Mobiltelefon-Dienstanforderer 54A zum Beispiel fordert einen Abbildungsdienst an, um Daten eines globalen Positionierungssystems (GPS) aufzuzeichnen, während der Dienstanforderer sich fortbewegt. Das Dienstverzeichnis erhält eine Anforderung 702 nach einem solchen Aufzeichnungsdienst für GPS-Daten, doch das Verzeichnis findet keinen spezifischen Dienstendpunkt, der dem Dienst zugeordnet ist. Das Verzeichnis findet jedoch einen Dienst mit dem Namen „GPS-Abbildungsdienst“ und einen Dienstanbieter „Telemaps Logger“, der dem Dienst zugeordnet ist. Das Dienstverzeichnis fordert in Schritt 708 einen Dienstendpunkt von „Telemaps Logger“ an. „Telemaps Logger“ empfängt die Anforderung für den Dienstendpunkt und richtet in Schritt 712 einen „GPS-Abbildungsdienst“ an einem Dienstendpunkt ein oder findet diesen Dienst dort, zum Beispiel die IP-Adresse 192.168.2.3 und den Anschluss 1200 (192.168.2.3:1200). Der Dienstanbieter „Telemaps Logger“ sendet anschließend in Schritt 714 den Dienstendpunkt an das Dienstverzeichnis zurück. Das Dienstverzeichnis 304 ordnet 192.168.2.3:1200 dem „GPS-Abbildungsdienst“ zu und sendet denselben Dienstendpunkt an das Mobiltelefon zurück. Das Mobiltelefon kann nun in Schritt 720 unter Verwendung des empfangenen Dienstendpunkts den Dienst von „Telemaps Logger“ anfordern. Telemaps Logger sendet den „GPS-Abbildungsdienst“ wieder zurück, wenn er am Dienstendpunkt 192.168.2.3:1200 angefordert wird. Der Dienst sendet zum Beispiel Abbildungsdaten mit der geografischen Position des Mobiltelefons, und die Abbildungsdaten werden von dem Mobiltelefon auf dem Bildschirm des Mobiltelefons wiedergegeben.
Unter Bezugnahme auf 8 folgt eine Beschreibung eines Durchführungsverfahrens 800 der bevorzugten Ausführungsform der Erfindung. Wie bei dem Verfahren 700 kann das Verfahren 800 ebenfalls für eine Ausführungsform in Bezug auf eine vollständige Dienst-Ressourcenbereitstellung mit geeigneten Änderungen angepasst werden. Der Prozess wird als Prozessschritte im Zusammenhang mit den Hauptkomponenten des SOA-Systems und insbesondere im Zusammenhang mit einem Dienstverzeichnis beschrieben.
Der Dienstanforderer 54A fordert in Schritt 802 einen Dienst mit einem festgelegten Leistungsniveau von einem Dienstanbieter an und leitet die Anforderung an das Dienstverzeichnis 304 weiter.
Das Dienstverzeichnis 304 durchsucht in Schritt 804 das Repository 514 nach einem Dienstendpunkt, der das festgelegte Leistungsniveau aufweist und der Dienstanforderung zugeordnet ist, wobei das Dienstverzeichnis nach dem bei dieser Ausführungsform behandelten Problem keinen zugeordneten Dienstendpunkt findet.
Wenn ein oder mehrere Dienstendpunkte lokalisiert werden, die den Dienst zwar bereitstellen, jedoch nicht mit dem erforderlichen Leistungsniveau, dann werden diese Dienstanbieter in einer Liste mit potenziellen Dienstanbietern aufgelistet. Wenn Dienstanbieter ohne Dienstendpunkte, die dem angeforderten Dienst zugeordnet sind, lokalisiert werden, dann werden diese Dienstanbieter ebenfalls in der Liste der potenziellen Dienstanbieter aufgelistet. In Schritt 806 wird ein erster Dienstanbieter aus der Liste der potenziellen Dienstanbieter ausgewählt; die Auswahl beruht darauf, inwieweit die Leistung des Dienstes mit dem geforderten Leistungsniveau übereinstimmt. Optional erhalten die Anbieter mit Dienstendpunkten eine höhere Priorität bei der Auswahl als Anbieter ohne Endpunkte. Wenn keine zugeordneten Dienstinformationen vorhanden sind, dann wird ein Standarddienstanbieter ausgewählt.
In Schritt 808 wird von dem ausgewählten Dienstanbieter ein Dienstendpunkt für den angeforderten Dienst angefordert.
Der ausgewählte oder Standarddienstanbieter 308N empfängt in Schritt 810 den angeforderten Dienst und wenn er die erforderliche Dienstleistung bereitstellen kann, richtet er in Schritt 812 einen Dienstendpunkt für den Dienst mit der definierten Dienstleistung ein. Wenn der Dienstanbieter die Dienstleistung nicht bereitstellen kann, dann wird die Anforderung abgelehnt und das Dienstverzeichnis muss in Schritt 806 einen anderen Dienstanbieter auswählen. Wenn der Dienstanbieter den Dienst bereitstellen kann, dann kann der Dienst bereits mit einem Dienstendpunkt eingerichtet sein, muss jedoch noch zusätzlich konfiguriert werden, um das richtige Leistungsniveau aufzuweisen. Der Dienst kann bereits mit dem richtigen Dienstleistungsniveau eingerichtet sein, jedoch ohne einen Dienstendpunkt; der Dienstanbieter muss in Schritt 814 nur einen zugeordneten Dienstendpunkt einrichten und diesen zurücksenden. Wenn der Dienst noch nicht eingerichtet ist, dann richtet ihn der Dienstanbieter entweder an einem bekannten Ort oder virtuell an einem unbekannten Ort ein. Der Dienstendpunkt wird unabhängig davon, ob er zuvor vorhanden war oder nicht, in Schritt 814 an das Verzeichnis 302 zurückgesendet.
Das Verzeichnis ordnet anschließend in Schritt 816 den registrierten Dienst mit dem definierten Leistungsniveau dem empfangenen Dienstendpunkt zu.
Das Verzeichnis sendet dann den empfangenen Dienstendpunkt in Schritt 818 an den Dienstanforderer 54A.
Bei dieser Ausführungsform fordert der Dienstanforderer 54A den Dienst in Schritt 820 von dem Dienstanbieter 302N am empfangenen Dienstendpunkt an. Bei dieser Ausführungsform wird der Dienstendpunkt einem definierten Leistungsniveau zugeordnet, so dass in der zweiten Anforderung kein definiertes Leistungsniveau angefordert werden muss. Bei anderen Ausführungsformen ist denkbar, dass ein Dienst an einem gegebenen Dienstendpunkt auf Anforderung vom Dienstanforderer variable Leistungsniveaus aufweist.
Der Dienstanbieter empfängt die Dienstanforderung am Dienstendpunkt und beginnt, den Dienst in Schritt 822 wieder zurück an den Dienstanforderer zu senden.
Der Mobiltelefon-Dienstanforderer 54A zum Beispiel fordert einen Abbildungsdienst an, um Daten eines globalen Positionierungssystems (GPS) aufzuzeichnen, während der Dienstanforderer sich fortbewegt, wobei er Aktualisierungen im Abstand von 1 Sekunde oder kürzer anfordert. In diesem Beispiel schließen Aktualisierungen im Abstand von 1 Sekunde den GPS-Standarddienst unseres Anforderers aus. Das Dienstverzeichnis erhält eine Anforderung 802 nach einem solchen Aufzeichnungsdienst für GPS-Daten, doch das Verzeichnis findet keinen spezifischen Dienstendpunkt, der dem Dienst zugeordnet ist. Das Verzeichnis findet jedoch einen Dienst mit dem Namen „Euro-GPS-Abbildungsdienst“, dessen Eigenschaft darin besteht, eine genaue Aktualisierung im Abstand von 0,8 Sekunden zu bieten, und das Verzeichnis weiß, dass 0,8 Sekunden kürzer als 1 Sekunde sind. Aus diesem Grund wird ein Dienstanbieter „Euro Map Logger“ dem Dienst zugeordnet. Das Dienstverzeichnis fordert in Schritt 808 einen Dienstendpunkt von „Euro Maps Logger“ an. „Euro Maps Logger“ empfängt die Anforderung für den Dienstendpunkt und richtet in Schritt 812 einen „Euro-GPS-Abbildungsdienst“ bei einem Dienstendpunkt ein oder findet diesen dort, zum Beispiel die IP-Adresse 214.168.2.3 und den Anschluss 2400 (214.168.2.3:2400). Der Dienstanbieter „Euro Maps Logger“ sendet anschließend in Schritt 814 den Dienstendpunkt an das Dienstverzeichnis zurück. Das Dienstverzeichnis 304 ordnet 214.168.2.3:2400 dem „Euro-GPS-Abbildungsdienst“ zu und sendet denselben Dienstendpunkt an das Mobiltelefon zurück. Das Mobiltelefon kann nun in Schritt 820 den Dienst unter Verwendung des empfangenen Dienstendpunkts von „Telemaps Logger“ anfordern. Telemaps Logger sendet den „GPS-Abbildungsdienst“ wieder zurück, wenn er am Dienstendpunkt 192.168.2.3:1200 angefordert wird. Der Dienst sendet zum Beispiel Abbildungsdaten mit der geografischen Position des Mobiltelefons, und die Abbildungsdaten werden von dem Mobiltelefon auf dem Bildschirm des Mobiltelefons wiedergegeben.
Unter Bezugnahme auf 9 folgt eine Beschreibung eines Suchverfahrens 900 einer Ausführungsform der Erfindung für einen Dienstverzeichnis-Vermittler. Wie bei den Verfahren 700 und 800 kann das Verfahren 900 ebenfalls für eine Ausführungsform in Bezug auf eine vollständige Dienst-Ressourcenbereitstellung mit geeigneten Änderungen angepasst werden. Der Prozess wird als Prozessschritte im Zusammenhang mit den Hauptkomponenten des SOA-Systems und insbesondere im Zusammenhang mit einem Dienstverzeichnis beschrieben.
Der Dienstanforderer 54A fordert von einem Dienstanbieter einen Dienst von dem ersten Dienstverzeichnis 304A.
Das erste Dienstverzeichnis 304A durchsucht in Schritt 904 das Repository 514 nach einem Dienstendpunkt, der der Dienstanforderung zugeordnet ist, wobei das erste Dienstverzeichnis 304A nach dem bei dieser Ausführungsform behandelten Problem keinen zugeordneten Dienstendpunkt findet.
Wenn keine zugeordneten Dienstinformationen vorhanden sind, kann gemäß vorheriger Ausführungsformen ein Standarddienstanbieter lokalisiert werden. Bei dieser Ausführungsform entscheidet das Dienstverzeichnis 304A, ob es Standarddienstanbieter verwendet oder die Anforderung an nachrangige Dienstverzeichnisse weiterleitet. Das Dienstverzeichnis verwendet einen Suchalgorithmus, der einen Relevanzwert für jeden der lokalisierten Dienstanbieter erzeugt, und wenn der Relevanzwert unter einem Schwellenwert liegt und ein zweites oder nachrangiges Dienstverzeichnis zum Abfragen vorhanden ist, dann fordert das Dienstverzeichnis 304A in Schritt 908 einen Dienstanbieter von einem zweiten (oder nachrangigen) Dienstverzeichnis 304B an. Die von dem ersten Dienstverzeichnis lokalisierten Dienstinformationen werden auch zu dem zweiten (oder nachrangigen) Dienstverzeichnis gesendet, so dass das zweite (oder nachrangige) Verzeichnis konsolidierte Dienstinformationen beim Auswählen eines Dienstanbieters verwenden kann.
Das zweite (oder nachrangige) Dienstverzeichnis 304B durchsucht in Schritt 910 das Verzeichnis nach einem Dienstendpunkt, der der Dienstanforderung zugeordnet ist. Für den Fall, dass eine genaue Übereinstimmung gefunden wird, wird ein Dienstendpunkt an das erste Dienstverzeichnis 304A zurückgesendet und der Prozess wird bei Schritt 920 fortgesetzt. Wenn keine genaue Übereinstimmung vorliegt, dann wählt das zweite Dienstverzeichnis in Schritt 912 einen lokalisierten Dienstanbieter oder einen Standarddienstanbieter. Das zweite Dienstverzeichnis 304B könnte ein nachrangiges Dienstverzeichnis ausgehend von der Relevanz der Suche auswählen, dies wird jedoch nicht gezeigt.
In Schritt 914 wird von dem ausgewählten Dienstanbieter ein Dienstendpunkt für den angeforderten Dienst angefordert.
Der ausgewählte Dienstanbieter 308N empfängt die Dienstanforderung und richtet den Dienst ein. Sobald der Dienst eingerichtet ist, ordnet der Dienstanbieter den Dienst einem Dienstendpunkt zu. Der Dienstendpunkt wird an das zweite Dienstverzeichnis 304B zurückgesendet.
Das zweite Dienstverzeichnis 304B ordnet anschließend in Schritt 916 den registrierten Dienst dem empfangenen Dienstendpunkt zu.
Das zweite Dienstverzeichnis 304B sendet dann in Schritt 918 den empfangenen Dienstendpunkt an das erste Dienstverzeichnis 304A.
Das erste Dienstverzeichnis 304A ordnet in Schritt 920 den registrierten Dienst dem empfangenen Dienstendpunkt zu.
Das erste Dienstverzeichnis 304A sendet dann in Schritt 922 den empfangenen Dienstendpunkt an den Dienstanforderer 54A.
Der Dienstanforderer 54A fordert den Dienst von dem Dienstanbieter 302N am empfangenen Dienstendpunkt (nicht dargestellt) an. Der Dienstanbieter empfängt die Dienstanforderung am Dienstendpunkt und beginnt, den Dienst wieder zurück an den Dienstanforderer (nicht dargestellt) zu senden.
Zusammenfassend sind ein Verfahren, ein System und ein Computerprogrammprodukt für eine dienstbasierte Implementierung in einem System beschrieben, das einer service-orientierten Architektur (SOA) entspricht. Das Verfahren, das System und das Computerprogrammprodukt können von einem Dienstverzeichnis in einem System mit service-orientierter Architektur zum Bereitstellen eines Dienstes in dem System ausgeführt werden und weisen die Schritte auf: Empfangen einer Dienstanforderung von einem Dienstanforderer im System, Prüfen des Status des Dienstes wie im Dienstverzeichnis registriert, gekennzeichnet durch Senden einer Anforderung an einen oder mehrere Dienstanbieter oder nachrangige Dienstverzeichnisse, um einen neuen Dienst bereitzustellen, als Reaktion darauf, dass der Dienst über keinen registrierten Dienstendpunkt verfügt oder dass eine Eigenschaft des Dienstes unter einen definierten Schwellenwert fällt, und Aktualisieren des Dienstverzeichnisses mit dem neuen Dienst und Benachrichtigen des Dienstanforderers, dass der Dienst zur Verfügung steht, als Reaktion darauf, dass ein Dienstanbieter den neuen Dienst bereitstellt. Die Ausführungsformen ermöglichen sowohl eine direkte Interaktion zwischen Anforderer und Anbieter als auch eine indirekte Interaktion über eine Dienstverwaltungsschicht. Die Ausführungsformen ermöglichen es auch, dass der Dienstanbieter als ein virtueller Server bereitgestellt wird und dass der Dienst als eine virtuelle Anwendung bereitgestellt wird.
HINWEISE
*BladeCenter*, DB2, IBM, Lotus, Tivoli, pSeries, WebSphere, xSeries und zSeries sind eingetragene Warenzeichen oder Warenzeichen der International Business Machines Corporation in den Vereinigten Staaten und/oder anderen Ländern.
** Java und alle auf Java beruhende Warenzeichen und Logos sind Warenzeichen oder eingetragene Warenzeichen von Oracle und/oder dessen Tochtergesellschaften.

Claims

Verfahren, das von einem Dienstverzeichnis in einer service-orientierten Umgebung zum Bereitstellen eines Dienstes in der Umgebung durchführbar ist, wobei das Verfahren die Schritte aufweist: - Empfangen einer Anforderung für einen Dienst von einem Dienstanforderer in der service-orientierten Umgebung; - Prüfen der Einzelheiten des angeforderten Dienstes wie im Dienstverzeichnis registriert; - gekennzeichnet durch: - Senden der Anforderung an einen oder mehrere Dienstanbieter, um einen neuen Dienst bereitzustellen, als Reaktion darauf, dass der angeforderte Dienst nicht registriert ist; und - Aktualisieren des Dienstverzeichnisses mit dem neuen Dienst und Benachrichtigen des Dienstanforderers, dass der Dienst zur Verfügung steht, als Reaktion darauf, dass ein Dienstanbieter den neuen Dienst bereitstellt; - als Reaktion darauf, dass der angeforderte Dienst nicht registriert ist, ◯ Senden der Dienstanforderung an eines oder mehrere nachrangige Dienstverzeichnisse, um einen Dienstanbieter für den Dienst bereitzustellen; ◯ Senden lokalisierter Dienstinformationen von dem ersten Dienstverzeichnis an ein oder mehrere nachrangige Dienstverzeichnisse, wobei Dienstanbieter lokalisiert werden durch die Dienstinformationen, die dem angeforderten Dienst zugeordnet sind, so dass es für das eine oder die mehreren nachrangigen Dienstverzeichnisse möglich ist, die durch das erste Dienstverzeichnis lokalisierten Dienstinformationen zu verwenden, um einen Dienstanbieter auszuwählen; und - Vermitteln zwischen dem Dienstanforderer und dem Dienstanbieter, wobei der Dienstanforderer den eigentlichen Dienstendpunkt des Dienstanbieters nicht empfängt, sondern den Dienst über die Dienstverwaltungsschicht verwendet.
Verfahren nach Anspruch 1, bei dem die Dienstanforderung einen erforderlichen Dienststandard beinhaltet und - als Reaktion darauf, dass der Dienst registriert ist, den erforderlichen Standard jedoch nicht aufweist, eine Anforderung an einen oder mehrere Dienstanbieter gesendet wird, um einen Dienst mit dem erforderlichen Standard bereitzustellen; und - als Reaktion darauf, dass ein Dienstanbieter einen Dienst mit dem erforderlichen Standard bereitstellt, das Dienstverzeichnis mit dem neuen Dienst und dem Dienststandard aktualisiert wird.
Verfahren nach Anspruch 2, wobei der Dienststandard darin besteht, dass eine Diensteigenschaft einen erforderlichen Schwellenwert erfüllt.
Verfahren nach Anspruch 2 oder 3, bei dem die Diensteigenschaft eines oder mehreres von Folgendem ist: - Rate der Durchführung des Dienstes; - Kosten des Dienstes; - oder Anzahl der bereitgestellten Dienstinstanzen.
Verfahren nach einem der Ansprüche 1 bis 4, bei dem der Dienstanforderer den Dienstendpunkt empfängt und den Dienst direkt vom Dienstanbieter anfordert.
Verfahren nach einem der Ansprüche 1 bis 5, bei dem der Dienstanbieter als ein virtueller Server bereitgestellt wird.
Verfahren nach einem der Ansprüche 1 bis 6, bei dem der Dienst als eine virtuelle Anwendung bereitgestellt wird.
Dienstverzeichnis in einem System mit einer service-orientierten Architektur zum Bereitstellen eines Dienstes in dem System, aufweisend: - ein Mittel zum Empfangen einer Anforderung für einen Dienst von einem Dienstanforderer in der service-orientierten Umgebung; - ein Mittel zum Prüfen der Einzelheiten des angeforderten Dienstes wie im Dienstverzeichnis registriert; - gekennzeichnet durch: - ein Mittel zum Senden der Anforderung an einen oder mehrere Dienstanbieter, um einen neuen Dienst bereitzustellen, als Reaktion darauf, dass der angeforderte Dienst nicht registriert ist; und - ein Mittel zum Aktualisieren des Dienstverzeichnisses mit dem neuen Dienst und Benachrichtigen des Dienstanforderers, dass der Dienst zur Verfügung steht, als Reaktion darauf, dass ein Dienstanbieter den neuen Dienst bereitstellt; - wobei das Mittel zum Senden, als Reaktion darauf, dass der angeforderte Dienst nicht registriert ist, dient zum ◯ Senden der Dienstanforderung an eines oder mehrere nachrangige Dienstverzeichnisse, um einen Dienstanbieter für den Dienst bereitzustellen; ◯ Senden lokalisierter Dienstinformationen von dem ersten Dienstverzeichnis an ein oder mehrere nachrangige Dienstverzeichnisse, wobei Dienstanbieter lokalisiert werden durch die Dienstinformationen, die dem angeforderten Dienst zugeordnet sind, so dass es für das eine oder die mehreren nachrangigen Dienstverzeichnisse möglich ist, die durch das erste Dienstverzeichnis lokalisierten Dienstinformationen zu verwenden, um einen Dienstanbieter auszuwählen; und - eine Dienstverwaltungsschicht zum Vermitteln zwischen dem Dienstanforderer und dem Dienstanbieter, wobei der Dienstanforderer den eigentlichen Dienstendpunkt des Dienstanbieters nicht empfängt, sondern den Dienst über die Dienstverwaltungsschicht verwendet.
Dienstverzeichnis nach Anspruch 8, bei dem die Dienstanforderung einen erforderlichen Dienststandard beinhaltet und - als Reaktion darauf, dass der Dienst registriert ist, den erforderlichen Standard jedoch nicht aufweist, eine Anforderung an einen oder mehrere Dienstanbieter gesendet wird, um einen Dienst mit dem erforderlichen Standard bereitzustellen; und - als Reaktion darauf, dass ein Dienstanbieter einen Dienst mit dem erforderlichen Standard bereitstellt, das Dienstverzeichnis mit dem neuen Dienst und dem Dienststandard aktualisiert wird.
Dienstverzeichnis nach Anspruch 9, bei dem der Dienststandard darin besteht, dass der Dienst über einen registrierten Dienstendpunkt verfügt.
Dienstverzeichnis nach Anspruch 9 oder 10, bei dem der Dienststandard darin besteht, dass eine Diensteigenschaft mit einem Schwellenwert übereinstimmt.
Dienstverzeichnis nach Anspruch 11, bei dem die Diensteigenschaft eines oder mehreres von Folgendem ist: - Rate der Durchführung des Dienstes; - Kosten des Dienstes; - Anzahl der bereitgestellten Dienstinstanzen; - oder eine beliebige andere variable Eigenschaft des Dienstes.
Dienstverzeichnis nach einem der Ansprüche 8 bis 12, bei dem der Dienstanforderer den Dienstendpunkt empfängt und den Dienst direkt von dem Dienstanbieter anfordert.
Dienstverzeichnis nach einem der Ansprüche 8 bis 13, bei dem der Dienstanbieter als ein virtueller Server bereitgestellt wird.
Dienstverzeichnis nach einem der Ansprüche 8 bis 14, bei dem der Dienst als eine virtuelle Anwendung bereitgestellt wird.
Computerprogrammprodukt, das ein computerlesbares Aufzeichnungsmedium mit einem darin gespeicherten computerlesbaren Code zum Ausführen eines Datenverzeichnisses in einem System mit einer service-orientierten Architektur und zum Verwalten eines Dienstes des Systems aufweist, wobei der computerlesbare Code die Schritte des Verfahrens nach einem der Ansprüche 1 bis 7 durchführt, wenn dieser in ein Computersystem geladen und dort ausgeführt wird.
Computerprogrammprodukt nach Anspruch 16, bei dem die Dienstanforderung einen erforderlichen Dienststandard beinhaltet und - als Reaktion darauf, dass der Dienst registriert ist, den erforderlichen Standard jedoch nicht aufweist, eine Anforderung an einen oder mehrere Dienstanbieter gesendet wird, um einen Dienst mit dem erforderlichen Standard bereitzustellen; und - als Reaktion darauf, dass ein Dienstanbieter einen Dienst mit dem erforderlichen Standard bereitstellt, das Dienstverzeichnis mit dem neuen Dienst und dem Dienststandard aktualisiert wird.
Computerprogrammprodukt nach Anspruch 17, bei dem der Dienststandard darin besteht, dass der Dienst über einen registrierten Dienstendpunkt verfügt.
Computerprogrammprodukt nach Anspruch 17 oder 18, bei dem der Dienststandard darin besteht, dass eine Diensteigenschaft einen Schwellenwert erfüllt.
Computerprogrammprodukt nach Anspruch 19, bei dem die Diensteigenschaft eines oder mehreres von Folgendem ist: - Rate der Durchführung des Dienstes; - Kosten des Dienstes; - Anzahl der bereitgestellten Dienstinstanzen; - oder eine beliebige andere variable Eigenschaft des Dienstes.
Computerprogrammprodukt nach einem der Ansprüche 16 bis 20, bei dem der Dienstanforderer den Dienstendpunkt empfängt und den Dienst direkt von dem Dienstanbieter anfordert.
Computerprogrammprodukt nach einem der Ansprüche 16 bis 21, bei dem der Dienstanbieter als ein virtueller Server bereitgestellt wird.
Computerprogrammprodukt nach einem der Ansprüche 16 bis 22, bei dem der Dienst als eine virtuelle Anwendung bereitgestellt wird.
Computerprogramm, das in einem computerlesbaren Medium gespeichert ist und in den internen Speicher eines digitalen Computers ladbar ist und Teile eines Softwarecodes aufweist, wenn das Programm auf einem Computer ausgeführt wird, um das Verfahren eines der Ansprüche 1 bis 7 durchzuführen.