[0001] Die Erfindung betrifft ein Verfahren zur Ausführung von Diensten in einem dezentralen
Datennetz sowie ein entsprechendes dezentrales Datennetz.
[0002] Aus dem Stand der Technik sind Verfahren bekannt, mit denen Rechenprozesse in der
Form von Diensten in einer verteilten Infrastruktur aus einer Mehrzahl von Rechnern
ausgeführt werden. Solche Infrastrukturen sind in der Regel nur schwer an variierende
Anforderungen in Bezug auf die auszuführenden Dienste anpassbar. Darüber hinaus ist
ein großer Administrationsaufwand zur Verwaltung der verteilten Ausführung von Diensten
erforderlich.
[0003] Aufgabe der Erfindung ist es deshalb, ein Verfahren zu schaffen, mit dem in einem
Datennetz eine einfache und flexibel anpassbare verteilte Ausführung von Diensten
ermöglicht wird.
[0004] Diese Aufgabe wird durch die unabhängigen Patentansprüche gelöst. Weiterbildungen
der Erfindung sind in den abhängigen Ansprüchen definiert.
[0005] Das erfindungsgemäße Verfahren verwendet zur Dienste-Ausführung ein dezentrales Datennetz,
bei dem die einzelnen Netzknoten gleichberechtigt sind, d.h. es gibt in dem Datennetz
keine zentrale Instanz, welche die Netzknoten in dem Datennetz verwaltet. Das Datennetz
ist dabei insbesondere ein Peer-to-Peer-Netz, wobei beliebige, aus dem Stand der Technik
bekannte Peer-to-Peer-Protokolle zur Bildung der Netzstruktur eingesetzt werden können.
In einer besonders bevorzugten Variante wird das aus dem Stand der Technik bekannte
Chord-Protokoll verwendet.
[0006] In dem erfindungsgemäßen Verfahren werden Ressourcen-Informationen über eine erste
Gruppe von ersten Netzknoten durch eine zweite Gruppe von zweiten Netzknoten bereitgestellt,
wobei die Ressourcen-Informationen die in den jeweiligen ersten Netzknoten verfügbaren
Ressourcen zur Ausführung von Diensten spezifizieren. Der Begriff der Ressource ist
dabei weit zu verstehen und Ressourcen-Informationen können beliebige Spezifikationen
der jeweiligen ersten Netzknoten umfassen, welche für die Ausführung von Diensten
relevant sind. Insbesondere betreffen Ressourcen statische oder dynamische Parameter
der jeweiligen Netzknoten, wie z.B. verfügbaren Speicherplatz und/oder verfügbare
Rechenleistung und/oder verfügbare Daten und/oder verfügbare Programme.
[0007] In dem erfindungsgemäßen Verfahren wird eine an das Datennetz gerichtete Dienste-Spezifikation,
welche eine oder mehrere auszuführende Dienste festlegt, innerhalb der zweiten Gruppe
von zweiten Netzknoten derart verarbeitet, dass basierend auf den Ressourcen-Informationen
eine Dienstegruppe umfassend zumindest einen ersten Netzknoten zur Ausführung des
oder der Dienste gemäß der Dienste-Spezifikation ausgewählt wird. Anschließend wird
an die ausgewählte Dienstegruppe die Dienste-Spezifikation übergeben und der oder
die Dienste gemäß der Dienste-Spezifikation werden durch die Dienstegruppe ausgeführt.
Eine Dienste-Spezifikation kann dabei beliebige Informationen in Bezug auf die Ausführung
eines oder mehrerer Dienste und damit festgelegter Kriterien enthalten. Wie weiter
unten erwähnt, können aus dem Stand der Technik bekannte Sprachen, beispielsweise
in der Form von Datenbank-Abfragesprachen, verwendet werden, um den Dienst und damit
verbundene Kriterien gemäß der Dienste-Spezifikation festzulegen. Unter bestimmten
Umständen kann in dem erfindungsgemäßen Verfahren der Fall auftreten, dass keine geeignete
Dienstegruppe gefunden wird und somit keine Dienstegruppe ausgewählt werden kann.
In diesem Fall wird das Verfahren beendet und gegebenenfalls eine Meldung ausgegeben,
dass die Ausführung des oder der Dienste gemäß der Dienste-Spezifikation in dem Datennetz
nicht möglich ist.
[0008] Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass in einem dezentralen
Datennetz die Verarbeitung von Diensten auf eine erste Gruppe von ersten Netzknoten
und eine zweite Gruppe von zweiten Netzknoten aufgeteilt wird. Die erste Gruppe von
ersten Netzknoten dient dabei zur Ausführung der Dienste und kann basierend auf einem
einfachen Peer-to-Peer-Protokoll verwaltet werden, denn sie muss keine komplexen Suchanfragen
verarbeiten. Demgegenüber übernimmt die zweite Gruppe von zweiten Netzknoten nicht
die Ausführung von Diensten, sondern ist speziell für die Auswahl von die Dienste
ausführenden Netzknoten in Abhängigkeit von der Dienste-Spezifikation und den hinterlegten
Ressourcen-Informationen vorgesehen. Dabei können die zweiten Netzknoten speziell
angepasst sein, um komplexe Anfragen basierend auf Dienste-Spezifikationen zu verarbeiten
bzw. Ressourcen-Informationen effizient in der zweiten Gruppe zu verteilen.
[0009] Durch die Verwendung von zwei Gruppen von Netzknoten, welche beide zu dem gleichen
dezentralen Datennetz gehören, wird somit eine einfache und flexible Verarbeitung
von Diensten geschaffen, wobei durch die Implementierung entsprechender Mechanismen
selbst komplexe Anfragen nach Diensten verarbeitet werden können. Ebenso können durch
die Erweiterung der ersten Gruppe um neue Netzknoten, welche in dezentralen Datennetzen
problemlos durchführbar ist, auch aufwändige Rechenprozesse durchgeführt werden.
[0010] In einer besonders bevorzugten Ausführungsform werden die Ressourcen-Informationen
innerhalb der zweiten Gruppe in einer oder mehreren Datenbanken abgelegt, wobei über
eine Datenbank-Abfrage die an das Datennetz gerichtete Dienste-Spezifikation verarbeitet
wird. Durch die Verwendung entsprechender, an sich aus dem Stand der Technik bekannter
Datenbank-Abfragesprachen können hierdurch auch komplizierte Dienste-Spezifikationen
mit einer Vielzahl von unterschiedlichen Kriterien im Hinblick auf die Ausführung
der Dienste verarbeitet werden. Dabei besteht die Möglichkeit, dass jeder zweite Netzknoten
eine Datenbank mit Ressourcen-Informationen zu allen ersten Netzknoten enthält. Gegebenenfalls
kann auch eine verteilte Datenbank eingesetzt werden, welche die Ressourcen-Informationen
mit geeigneten Algorithmen auf die zweiten Netzknoten der zweiten Gruppe verteilt.
In einer bevorzugten Ausführungsform wird als Datenbank eine Peer-to-Peer-Datenbank
verwendet. Peer-to-Peer-Datenbanken sind dem Fachmann geläufig. Es handelt sich hierbei
um lose gekoppelte, hoch verteilte Datenverwaltungssysteme, an denen eine Vielzahl
von Rechnern beteiligt ist.
[0011] In einer besonders bevorzugten Ausführungsform umfasst die Dienste-Spezifikation
eine Beschreibung der durch den oder die Dienste durchzuführenden Aufgabe und einen
Regelsatz, der eine oder mehrere Anforderungen an die zur Ausführung des oder der
Dienste zu verwendenden Dienstegruppe enthält. Dieser Regelsatz kann beliebig ausgestaltet
sein und verschiedene Kriterien festlegen. In einer Variante der Erfindung umfasst
ein Kriterium des Regelsatzes das Kriterium, dass die Ausführung des oder der Dienste
wenig Energie verbraucht. Dieses Kriterium kann dabei derart umgesetzt werden, dass
bei der Ausführung des oder der Dienste erste Netzknoten mit physikalisch entfernt
voneinander angeordneter Hardware und/oder erste Netzknoten mit geringem Energieverbrauch
(d.h. mit gutem Energiemanagement) bevorzugt verwendet werden.
[0012] In einer einfachen Ausführungsform der Erfindung umfasst die Dienstegruppe zur Ausführung
des oder der Dienste lediglich einen einzelnen ersten Netzknoten. In einer besonders
bevorzugten Variante der Erfindung umfasst die ausgewählte Dienstegruppe jedoch mehrere
erste Netzknoten, welche zumindest einen Koordinator-Knoten zur Koordinierung der
Ausführung des oder der Dienste gemäß der Dienste-Spezifikation und zumindest einen
ausführenden Netzknoten zur Ausführung des oder der Dienste gemäß der Dienste-Spezifikation
beinhalten. Auf diese Weise kann eine effiziente Ausführung auch von komplexen Diensten
erreicht werden.
[0013] In einer weiteren Variante der Erfindung umfasst die ausgewählte Dienstegruppe neben
dem zumindest einen Koordinator-Knoten und dem zumindest einen ausführenden Netzknoten
zumindest einen Überwachungsknoten, der die Ausführung des oder der Dienste überwacht
und die Aufgabe eines Koordinator-Knotens oder eines ausführenden Netzknotens übernehmen
kann, insbesondere bei Ausfall eines Koordinator-Knotens oder eines ausführenden Netzknotens.
Hierdurch kann die Verlässlichkeit der Ausführung der Dienste in dem Datennetz deutlich
erhöht werden, da bei Ausfall eines Knotens in der Dienstegruppe dessen Aufgabe durch
den Überwachungsknoten übernommen werden kann.
[0014] Um eine schnelle Migration eines oder mehrerer Dienste auf einen Überwachungsknoten
zu erreichen, werden in einer besonders bevorzugten Ausführungsform in dem zumindest
einen Überwachungsknoten in regelmäßigen Abständen der aktuelle Rechenzustand (d.h.
der Ausführungszustand des oder der Dienste) des zumindest einen Koordinatenknotens
und/oder des zumindest einen ausführenden Netzknotens hinterlegt. Es kann somit auf
einfache Weise der Zustand des entsprechenden Netzknotens bei dessen Ausfall durch
denjenigen Überwachungsknoten wiederhergestellt werden, der die Aufgabe des ausgefallenen
Knotens übernimmt.
[0015] In einer weiteren, besonders bevorzugten Ausführungsform ist die Dienstegruppe bei
der Ausführung des oder der Dienste gemäß der Dienste-Spezifikation basierend auf
einem oder mehreren Kriterien dynamisch veränderbar, wobei insbesondere die Ausführung
eines Dienstes von einem ausführenden Netzknoten auf einen anderen Netzknoten übertragen
wird, wenn der andere Netzknoten gemäß dem oder den Kriterien besser zur Ausführung
des Dienstes geeignet ist. Durch diese dynamische Anpassung der Dienstegruppe kann
die Ausführung der Dienste in bestimmten Fällen weiter beschleunigt werden. Die Kriterien,
unter welchen Bedingungen die Dienstegruppe verändert wird, können dabei beliebig
festgelegt sein. Beispielsweise kann ein Ersatz eines ausführenden Netzknotens durch
einen anderen Netzknoten erfolgen, wenn die verfügbare Rechenleistung des anderen
Netzknotens um ein vorbestimmtes Maß größer ist als die Rechenleistung des aktuell
den Dienst ausführenden Netzknotens.
[0016] Um eine effiziente Verteilung der Ressourcen-Informationen in der zweiten Gruppe
der zweiten Netzknoten zu erreichen, wird in einer bevorzugten Ausführungsform ein
geeignetes Protokoll verwendet. Insbesondere kann dabei ein auf Gossip basierendes
Protokoll verwendet werden, wobei die Gossip-Methode hinlänglich aus dem Stand der
Technik bekannt ist. In einer Variante der Erfindung wird das in dem Dokument [1]
beschriebene Protokoll eingesetzt.
[0017] Die Dienste-Spezifikation kann an die zweite Gruppe von zweiten Netzknoten über eine
beliebige Schnittstelle übergeben werden. In einer besonders bevorzugten Variante
wird dabei eine Web-Service-Schnittstelle eingesetzt.
[0018] In einer weiteren, bevorzugten Ausführungsform der Erfindung lädt ein zur Ausführung
eines Dienstes in der ausgewählten Dienstegruppe bestimmter Netzknoten Software-Code
zur Ausführung des Dienstes von einem anderen Netzknoten, falls der zur Ausführung
bestimmte Netzknoten keinen Software-Code zur Ausführung des Dienstes enthält. Auf
diese Weise kann ein zur Ausführung eines Dienstes besonders geeigneter Netzknoten
auch unabhängig davon ausgewählt werden, ob auf diesem Netzknoten bereits der Software-Code
zur Dienste-Ausführung hinterlegt ist. Aus dem Stand der Technik sind dabei entsprechende
Verfahren bekannt, wie dezentral und dynamisch Software-Code auf einen Netzknoten
geladen werden kann (siehe z.B. Dokument [2]).
[0019] Die in dem erfindungsgemäßen Verfahren ausgeführten Dienste können gegebenenfalls
basierend auf einem vorgegebenen Standard beruhen. In einer bevorzugten Variante stellen
die im Datennetz ausgeführten Dienste dabei sog. OSGi-Services dar (OSGi = Open Services
Gateway Initiative).
[0020] Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein dezentrales
Datennetz zur Ausführung von Diensten, umfassend eine Vielzahl von Netzknoten, wobei
eine erste Gruppe von ersten Netzknoten und eine zweite Gruppe von zweiten Netzknoten
vorgesehen ist, welche derart ausgestaltet sind, dass jede Variante des oben beschriebenen
Verfahrens in dem Datennetz durchführbar ist.
[0021] Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren
detailliert beschrieben.
[0022] Es zeigen:
- Fig. 1
- eine schematische Darstellung einer Ausführungsform eines Peer-to-Peer-Netzes, in
dem das erfindungsgemäße Verfahren durchführbar ist;
- Fig. 2
- eine schematische Darstellung des Ablaufs einer Ausführungsform des erfindungsgemäßen
Verfahrens in dem Peer-to-Peer-Netz der Fig. 1; und
- Fig. 3
- ein Diagramm, welches die Ergebnisse einer basie-rend auf dem erfindungsgemäßen Verfahren
durchgeführten Simulation zeigt.
[0023] Im Folgenden wird anhand von Fig. 1 ein Beispiel eines Peer-to-Peer-Netzes beschrieben,
in dem das erfindungsgemäße Verfahren durchführbar ist. Das Netz der Fig. 1 beruht
dabei auf dem hinlänglich aus dem Stand der Technik bekannten Chord-Protokoll, bei
dem die einzelnen Netzknoten, welche im Folgenden auch als Peers bezeichnet werden,
auf einem logischen Ring angeordnet sind. Dabei verwaltet jeder Peer über eine verteilte
Hash-Tabelle, welche auch als DHT (Distributed Hash Table) bezeichnet wird, ein Werteintervall
innerhalb eines Hash-Wertebereichs. Gemäß der Ausführungsform der Fig. 1 existiert
eine Gruppe von ersten Peers P1, P2, ..., P7, welche zur Ausführung von Diensten in
dem Peer-to-Peer-Netz vorgesehen sind. Darüber hinaus existiert eine Gruppe von zweiten
Peers P8, P9, ..., P14, welche ebenfalls auf dem Ring angeordnet sind, wobei die Anordnung
auf dem Ring aus Übersichtlichkeitsgründen nicht für alle Peers P8 bis P14 wiedergegeben
ist. Da die Peers P1 bis P7 zur Ausführung von Diensten vorgesehen sind, werden sie
im Folgenden auch als Service-Peers bezeichnet.
[0024] Im Unterschied zu den Service-Peers stellen die Peers P8 bis P14 sog. Index-Peers
dar, deren Aufgabe nicht in der Ausführung von Diensten besteht, sondern in der Verwaltung
entsprechender Informationen betreffend die verfügbaren Ressourcen der jeweiligen
Service-Peers P1 bis P7. Der Begriff der Ressource ist dabei weit zu verstehen und
betrifft insbesondere die auf den einzelnen Peers verfügbaren Hardware- und/oder Software-Ressourcen,
z.B. auf den Peers verfügbarer Speicherplatz, verfügbare Rechenleistung, verfügbare
Programme und/oder Daten. Der Grund für die Verwendung von Index-Peers liegt darin,
dass über die DHT-Tabelle nur basierend auf einfachen Anfragen mittels entsprechender
Schlüsselwörter, welche auf dem Hash-Wertebereich abgebildet werden, nach Ressourcen
gesucht werden kann. Demzufolge können komplexe Anfragen, wie z.B. semantische oder
Bereichs-Anfragen, über große Datensätze hinweg nicht bzw. nur sehr schlecht allein
über die Peers P1 bis P7 verarbeitet werden. Deshalb werden die Index-Peers verwendet,
welche eine spezielle Gruppe von Peers darstellen, welche Informationen bezüglich
der Ressourcen der Service-Peers in der Form von Metadaten und entsprechenden Statusinformationen
derart bereitstellen, dass auch komplexe Anfragen verarbeitet werden können. Hierdurch
wird eine Plattform ermöglicht, die in der Lage ist, effizient für einen auszuführenden
Dienst die aktuell am besten geeigneten Peers zu bestimmen, z.B. Peers, welche bestimmten
Fähigkeiten aufweisen bzw. inaktive Hardware-Ressourcen enthalten.
[0025] Die Index-Peers stellen somit verbesserte Anfrage-Schnittstellen zur Verfügung, um
hierdurch auch bei komplexen Anfragen einen internen Auswahlprozess für die zur Dienste-Ausführung
zu verwendenden Peers zu gewährleisten. Um die Verarbeitungsgeschwindigkeit von Anfragen
zu erhöhen, enthalten die Index-Peers der Fig. 1 einen separaten Pool von Verbindungen
zu anderen Index-Peers. Diese zusätzlichen Verbindungen gehen über die üblichen Verbindungen
auf dem Chord-Ring hinaus. Die Verwaltung und Verteilung von Ressourcen-Informationen
in der Gruppe der Index-Peers wird dabei mit einem separaten Protokoll gewährleistet,
wobei in der Ausführungsform der Fig. 1 ein auf Gossip basierendes Protokoll verwendet
wird, mit dem effizient und schnell Informationen zwischen den Peers verteilt und
ausgetauscht werden können. Dieses Protokoll wird in der Druckschrift [1] beschrieben.
[0026] Die Service-Peers P1 bis P7 des Netzes der Fig. 1 machen ihre jeweiligen Ressourcen
zur Ausführung von Diensten in dem Netz bekannt. Diese Informationen werden dann in
geeigneter Weise in der Gruppe der Index-Peers verteilt und für Anfragen genutzt,
wie weiter unten beschrieben wird. Jeder Service-Peer beinhaltet in der Ausführungsform
der Fig. 1 einen sog. OSGi-Service-Container, wobei die OSGi-Plattform zur Ausführung
von Diensten hinlänglich aus dem Stand der Technik bekannt ist. Die Bereitstellung
von Diensten im Rahmen eines OSGi-Service-Containers ist in Fig. 1 am Beispiel des
Peers P3 verdeutlicht. Dabei enthält die Plattform PH (PH = Peer Host) des Peers P3
den OSGi-Service-Container SC, in dem eine Mehrzahl von Diensten SE1, SE2, ..., SE6
enthalten ist. Die Dienste SE1 bis SE4 können beliebig ausgestaltet sein und sind
in Fig. 1 Standard-Dienste innerhalb des Service-Containers SC. Dabei betrifft SE1
einen Kommunikations-Dienst, SE2 einen Scheduling-Dienst, SE3 einen Datenspeicher-Dienst
und SE4 einen Dienst zur Verwaltung der Dienste-Ausführung. Durch die Dienste SE5
und SE6 werden Dienste spezifiziert, welche dynamisch während der Laufzeit durch den
Peer in den Service-Container integriert werden, indem sie beispielsweise von anderen
Peers geladen werden.
[0027] Fig. 2 verdeutlicht am Beispiel des Peer-to-Peer-Netzes der Fig. 1 die Dienste-Ausführung
basierend auf einem Ausführungsbeispiel der Erfindung. In einem durch einen entsprechenden
Pfeil angedeuteten Schritt S1 wird über einen Rechner eines Benutzers U eine Anfrage
zur Ausführung eines oder mehrerer Dienste an das Peer-to-Peer-Netz gerichtet. Dies
geschieht dadurch, dass eine Dienste-Spezifikation SP über eine Web-Service-Schnittstelle
WSI des Index-Peers P14 in die Gruppe der Index-Peers P8 bis P14 eingespeist wird.
Die Dienste-Spezifikation enthält dabei eine Beschreibung der durchzuführenden Aufgabe
des oder der angefragten Dienste zusammen mit einem Satz von Regeln, welche nicht-funktionale
Anforderungen an die Dienste-Ausführung, beispielsweise hierfür benötigte Ressourcen
oder Kriterien im Hinblick auf einen geringen Energieverbrauch bei der Dienste-Ausführung
und dergleichen, enthalten. Jeder der Index-Peers P8 bis P14 verfügt dabei über eine
Web-Service-Schnittstelle WSI, wobei die Dienste-Spezifikation über eine beliebige
der Web-Service-Schnittstellen der Index-Peers eingespeist werden kann. Jeder der
Index-Peers kann somit als ein Gateway zum Empfang einer entsprechenden Dienste-Spezifikation
dienen.
[0028] Nach der Einspeisung der Dienste-Spezifikation SP in die Gruppe der Index-Peers löst
der Index-Peer P14 einen entsprechenden Auswahlprozess zur Bestimmung möglicher Peer-Kandidaten
zur Ausführung der Dienste aus. Die Auswahl entsprechender Peers kann dabei basierend
auf an sich bekannten Datenbank-Abfragen erfolgen. In der Ausführungsform der Fig.
2 enthält jeder der Service-Peers eine lokale Datenbank DB, in der Ressourcen-Informationen
zu allen Peers P1 bis P7 gespeichert sind, wobei im Szenario der Fig. 2 auf die lokale
Datenbank des Peers P14 zurückgegriffen wird. Die Ressourcen-Informationen werden
somit redundant in lokalen Datenbanken in jedem Index-Peer hinterlegt. Gegebenenfalls
besteht auch die Möglichkeit, mit entsprechenden Algorithmen eine oder mehrere verteilte
Datenbanken innerhalb der Gruppe der Index-Peers zu erzeugen. Die Durchführung von
Abfragen und die Suche nach Informationen innerhalb von Datenbanken sind an sich aus
dem Stand der Technik in einer Vielzahl von Varianten bekannt. Die konkrete Ausführung
und Realisierung einer entsprechenden Datenbank und geeigneter Suchanfragen liegt
somit im Rahmen von fachmännischem Handeln. Insbesondere kann dabei auf gängige Datenbanken
und Abfragesprachen zur konkreten Realisierung zurückgegriffen werden.
[0029] Basierend auf der Dienste-Spezifikation SP, welche wie oben erwähnt über eine Datenbank-Abfrage
formuliert sein kann, wird der Auswahlprozess basierend auf den Ressourcen-Informationen
in der lokalen Datenbank DB durchgeführt, um Peers herauszufiltern, welche in der
Lage sind, die entsprechende Aufgabe gemäß der Beschreibung in der Dienste-Spezifikation
durchzuführen. Anschließend werden die ermittelten Kanditaten-Peers nochmals gefiltert,
wobei der in der Dienste-Spezifikation enthaltene Regelsatz auf die Kandidaten-Peers
angewendet wird. Die verbleibende Anzahl an Peers wird dann basierend auf einem oder
mehreren Kriterien bewertet, um die für die Koordination und Ausführung des oder der
Dienste gemäß der Dienste-Spezifikation am besten geeigneten Peers herauszufinden.
Dabei liegt es im Rahmen von fachmännischem Handeln, entsprechende Kriterien zur Auswahl
der am besten geeigneten Peers festzulegen und in dem erfindungsgemäßen Verfahren
zu implementieren. Insbesondere können die besten Peer-Kandidaten basierend auf deren
statischen Fähigkeiten (d.h. basierend auf der Hardware, der Netzwerkbandbreite und
dergleichen), auf dem aktuellen Zustand der Peers (die momentane Last bzw. den Status
anderer Ressourcen und dergleichen) sowie beliebiger zusätzlicher Kriterien bestimmt
werden, wobei die Berücksichtigung dieser Kriterien bei der Auswahl des Peers in dem
entsprechenden Regelsatz der Dienste-Spezifikation SP hinterlegt ist.
[0030] Die im Vorangegangenen beschriebene Auswahl geeigneter Peers zur Ausführung der entsprechenden
Dienste ist in Fig. 2 durch Schritt S2 angedeutet, der in der Form von ineinander
greifenden Pfeilen wiedergegeben ist. Im Beispiel der Fig. 2 wurde dabei die Anfrage
und die Auswahl des geeigneten Service-Peers durch den Index-Peer P14 durchgeführt.
Die Anfrage kann jedoch auch über die Web-Service-Schnittstelle eines beliebigen anderen
Peers empfangen werden und dort verarbeitet werden.
[0031] In der hier beschriebenen Ausführungsform der Erfindung werden die Dienste nicht
basierend auf einem einzelnen Service-Peer ausgeführt, sondern bei der Durchführung
der Dienste wird immer eine Gruppe von mehreren Peers verwendet, wobei diese Gruppe
immer drei Peers umfasst. Demzufolge wird nach der Auswahl der am besten zur Dienste-Ausführung
geeigneten Kandidaten-Peers eine Konfiguration einer Service-Gruppe gemäß der Dienste-Spezifikation
erzeugt. In dem Beispiel der Fig. 2 ist diese Service-Gruppe als SG bezeichnet und
umfasst die Peers P2, P3 und P4. Dabei ist der Peer P2 ein sog. Koordinator-Peer,
der die Ausführung der Dienste koordiniert. Die eigentliche Ausführung der Dienste
erfolgt über den ausführenden Peer P3, wobei in anderen Varianten gegebenenfalls auch
mehrere Peers zur Dienste-Ausführung vorgesehen sein können. Darüber hinaus ist der
Peer P4 als Überwachungs-Peer in der Form eines sog. Watchdogs vorgesehen, wobei in
anderen Varianten gegebenenfalls auch mehrere Watchdogs in der Service-Gruppe vorhanden
sein können. Die Watchdogs überwachen den Koordinator-Peer und dienen als Backups,
welche in regelmäßigen Abständen den Ausführungszustand der Dienste speichern, um
gegebenenfalls bei Ausfall eines ausführenden Peers bzw. des Koordinator-Peers dessen
Aufgaben zu übernehmen. Die Festlegung der Anzahl von ausführenden Peers bzw. Watchdogs
sowie die Intervalle, in denen der Zustand der Ausführung durch die Watchdogs überwacht
wird, kann beispielsweise über sog. QoS-Regeln (QoS = Quality of Service) reguliert
werden.
[0032] Nach der Konfiguration der Service-Gruppe wird die Dienste-Spezifikation SP schließlich
an den Koordinator-Peer P2 der Service-Gruppe SG übergeben, was in Fig. 2 durch den
Schritt S3 in der Form eines Pfeils angedeutet wird. Anschließend erfolgt die Ausführung
der Dienste innerhalb der Service-Gruppe SG.
[0033] In der soeben beschriebenen Ausführungsform kann unter Umständen der Fall auftreten,
dass ein Peer zur Ausführung eines Dienstes ausgewählt wird, der den hierfür benötigten
Software-Code in der Form eines Service-Code-Bundles oder andere Daten, welche gemäß
der Dienste-Beschreibung bei der Dienste-Ausführung benötigt werden, nicht bereitstellt.
In diesem Fall besteht die Möglichkeit, dass noch fehlende Informationen von anderen
Service-Peers geladen werden und dynamisch in dem bereits oben beschriebenen lokalen
OSGi-Container SC als Service hinterlegt werden. Entsprechende Prozesse zur Publikation,
zur Suche, zur Auswahl einer Implementierung sowie zum endgültigen Laden eines Plattform-spezifischen
Service-Codes sind dabei aus dem Stand der Technik bekannt. Beispielsweise kann das
Verfahren gemäß der Druckschrift [2] verwendet werden, welche das dynamische Laden
von OSGi-Bundles beschreibt. Dieses Verfahren betrifft einen generischen und dezentralen
Auswahlprozess, der die Identifikation des am besten geeigneten Service-Code-Bundles
für eine bestimmte Plattform ermöglicht. Dabei werden drei Kategorien von Eigenschaften
und Anforderungen während des Auswahlprozesses berücksichtigt, nämlich die erforderliche
Schnittstelle für das Service-Code-Bundle, funktionale und nicht-funktionale Eigenschaften
und Kompatibilitäts-Erfordernisse, beispielsweise die erforderliche Programmiersprache
sowie die lokale Ausführungsumgebung.
[0034] Wie bereits erwähnt, wird nach der Bildung der Service-Gruppe und gegebenenfalls
nach dem Laden der erforderlichen Ausführungs-Logik von einem anderen Peer, die Dienste-Spezifikation
an den Koordinator-Peer übertragen, in dem die Ausführungs-Logik parametrisiert ist
und demzufolge die Ausführung unter Verwendung des ausführenden Netzknotens zeitlich
festgelegt werden kann. Während der Ausführung fungiert der Koordinator-Peers als
Leiter der Service-Gruppe und stimmt sich mit den Watchdogs (und den Index-Peers)
ab, um die Gruppe aufrecht zu erhalten. In einer bevorzugten Ausführungsform können
dabei während der Laufzeit durch den Koordinator-Peer besser für die Dienste-Ausführung
geeignete Peers aufgefunden werden, welche das dezentrale Netz z.B. zu einem späteren
Zeitpunkt betreten haben, und der Koordinator kann dann die Dienste-Ausführung auf
diese Peers übertragen.
[0035] Der oder die ausführenden Peers in einer Service-Gruppe verwenden vorzugsweise einen
sog. Checkpointing-Mechanismus, um aktualisierte Ausführungszustände an die Watchdogs
zu übertragen. Dabei werden die zeitlichen Intervalle zur Durchführung des Checkpointings
wiederum durch eine Regel kontrolliert. Sollte ein besser geeigneter Peer gefunden
werden, kann gegebenenfalls der aktuelle Ausführungszustand von dem aktuell ausführenden
Peer an den neuen, besser geeigneten Peer migriert werden.
[0036] Aktuelle Prozesszustände der ausgeführten Dienste sowie deren Ergebnisse werden an
den Rechner des Benutzers U entweder wiederum über die Web-Service-Schnittstelle WSI
zurückgegeben oder an eine andere Stelle, welche durch den Dienst spezifiziert ist.
Die Dienste-Ausführung ist beendet, falls der Dienst die spezifizierte Ausgabe erfolgreich
ausgeführt hat oder ein fataler Fehler aufgetreten ist. In beiden Fällen wird die
Service-Gruppe durch den Koordinator-Peer aufgelöst und die Ressourcen werden an die
Peers der Index-Gruppe wieder als verfügbar gemeldet.
[0037] Bei der Ausführung der Dienste im Rahmen der Service-Gruppe hat der Koordinator-Peer
eine zentrale Rolle. Falls dieser Peer während der Dienste-Ausführung ausfällt, kann
die Service-Gruppe unter Umständen einen inkonsistenten Zustand einnehmen. In diesem
Fall wird in der hier beschriebenen Ausführungsform ein neuer Koordinator-Peer unter
den Watchdogs basierend auf einer generischen Consensus-Protokoll-Instanz ausgewählt,
wobei dieses Auswahlverfahren in der Druckschrift [3] beschrieben ist. Dabei besteht
die Möglichkeit, dass dieses Auswahlverfahren als Standard-Service in der Plattform
der Peers hinterlegt ist. Das verwendete Verfahren ermöglicht die Sicherstellung der
Konsistenz von verteiltem Konsens zwischen den Peers für verschiedene Ausfallmodelle
der Peers.
[0038] Das im Vorangegangenen beschriebene erfindungsgemäße Verfahren ermöglicht die verteilte
Ausführung von beliebigen Arten von Diensten. Speziell eignet sich das Verfahren beispielsweise
für die Simulation von großen verteilten Systemen. Große verteilte Systeme beschreiben
Prozesse, welche zwischen einer Vielzahl von beliebig gearteten Knoten ablaufen, wobei
ein verteiltes System mit solchen Knoten in einem dezentralen Peer-to-Peer-Netz simuliert
werden kann. Hierbei ist zu beachten, dass die (simulierten) Knoten des verteilten
Systems nicht den Peers entsprechen. Vielmehr simulieren die jeweiligen Peers eine
Vielzahl von Knoten in dem verteilten System.
[0039] In einer speziellen Ausführungsform wird in der oben beschriebenen Peer-to-Peer-Plattform
der Dienst eines verteilten Simulators ausgeführt. Der Simulator besteht dabei aus
drei wesentlichen Komponenten, nämlich dem Simulator-Code, d.h. das Programm, das
die Simulation ausführt, den Simulations-Codes, d.h. das Programm, das die Simulation
beschreibt, und den Simulations-Parametern, welche der oben beschriebenen Dienste-Spezifikation
entsprechen. Der Simulator-Code ist dabei beispielsweise als OSGi-Service-Bundle implementiert
und der Simulations-Code kann ebenfalls in einem OSGi-Bundle verpackt sein. Beispielsweise
kann die Simulation in Java- oder C-Code implementiert sein. Die entsprechende Dienste-Beschreibung
basierend auf den Simulations-Parametern kann beispielsweise in einer XML-formatierten
Textdatei hinterlegt sein. Die Dienste-Beschreibung umfasst dabei Parameter betreffend
die Anzahl von ausführenden Peers und Watchdogs, die Anzahl von simulierten Knoten
und die Anzahl an durchzuführenden Simulationsläufen, Parameter in Bezug auf eine
Nachverarbeitung der Ergebnisse sowie andere, für die Simulation spezifische Parameter.
Gegebenenfalls können einige Simulationen Daten benötigen, welche Netzwerk-Topologien
oder Transmissions-Latenzen beschreiben. Diese Informationen können z.B. unter der
Verwendung eines Speicher-Dienstes oder anderer, in der Dienste-Beschreibung spezifizierter
Mechanismen heruntergeladen werden.
[0040] Bei der Durchführung von Simulationen gemäß dem obigen Beispiel löst der Koordinator-Peer
nach Empfang der Dienste-Spezifikation die Ausführung des verteilten Simulators aus.
Während der Ausführung weist der Koordinator-Peer Aufgaben den einzelnen ausführenden
Peers zu und fungiert als Aggregator für die entsprechenden Ergebnisse der Ausführung.
Zusätzlich werden Ergebnisse und Status-Informationen kontinuierlich an den Benutzer
zurückgegeben, wodurch eine Echtzeit-Überwachung der Simulation ermöglicht wird.
[0041] Die Performanz des im Vorangegangenen beschriebenen Verfahrens hängt insbesondere
davon ab, wie gut die Dienste überwacht werden, wie schnell eine Migration eines Dienstes
von einem Peer auf einem anderen ermöglicht wird und wie gut der oben beschriebene
Checkpointing-Mechanismus funktioniert. Im Folgenden wird dargelegt, wie diese Faktoren
die Dienste-Ausführung beeinflussen.
[0042] Hohe Verfügbarkeit der Peers bei der Dienste-Ausführung wird über den im Vorangegangenen
beschriebenen Watchdog-Mechanismus erreicht. Die Anzahl von Watchdogs kann dabei in
Abhängigkeit von der durch den Dienst auszuführenden Aufgabe festgelegt sein. Im Regelfall
ist es ausreichend, wenn die Service-Gruppe drei Peers, umfassend einen Koordinator-Peer,
einen ausführenden Peer und einen Watchdog, enthält. Geht man beispielsweise von dem
realistischen Szenario aus, bei dem ein Peer im Durchschnitt eine zusammenhängende
Verfügbarkeitszeit von 30 Minuten aufweist und die durchschnittliche Ausführung eines
Dienstes eine Minute beträgt, so ergibt sich die Wahrscheinlichkeit P für einen Fehler
bei der Dienste-Ausführung zu:
für den Fall, dass keine Watchdogs in der Service-Gruppe verwendet werden. Wenn Watchdogs
hinzugefügt werden, kann die Ausfallwahrscheinlichkeit P basierend auf folgender Formel
vermindert werden:
[0043] Dabei bezeichnet k die Anzahl an Watchdogs. Man erkennt, dass eine Verfügbarkeit
für eine Dienste-Ausführung von 99,999 % mit lediglich zwei Watchdogs erreicht werden
kann. In den meisten Fällen ist es deshalb bei der Umsetzung der Erfindung ausreichend,
wenn ein oder zwei Watchdogs eingesetzt werden. Die obige Formel geht davon aus, dass
die Ausfälle von Watchdogs nicht korreliert sind. Diese Annahme ist realistisch, denn
die Peers in den Service-Gruppen werden in der Regel unabhängig von ihrem physikalischen
Ort zusammengesetzt.
[0044] Eine konkrete Implementierung des oben beschriebenen erfindungsgemäßen Verfahrens
wurde von den Erfindern in einem Peer-to-Peer-Netz aus neun herkömmlichen PCs getestet.
Als Dienst wurde dabei eine Variante des oben beschriebenen verteilten Simulators
zur Simulation einer Vielzahl von Knoten verwendet. Es konnte gezeigt werden, dass
in dieser konkreten Implementierung Migrationszeiten von einem ausführenden Peer auf
einen anderen Peer von deutlich weniger als einer Sekunde für Zustände von der Größe
von 10 Kilobyte erreicht werden, wenn die Migration aufgrund des Auffindens eines
für die Dienste-Ausführung besser geeigneten Peers ausgelöst wird. Die Migrationszeiten
für den Fall eines unvorhersehbaren Peer-Ausfalls sind etwas länger.
[0045] Fig. 3 zeigt für die getesteten verteilten Simulationen die Abhängigkeit der Anzahl
der für die Dienste-Ausführung verwendeten Peers von der Anzahl der durch die Simulation
simulierten Knoten. Entlang der Abszisse sind dabei die Anzahl NP der ausführenden
Peers und entlang der Ordinate die Anzahl NN der simulierten Knoten angedeutet. Man
erkennt, dass mit acht ausführenden Peers eine Simulation von 500000 Knoten erreicht
wird. Man erkennt in Fig. 3 ferner, dass die Anzahl der simulierten Knoten fast linear
mit der Anzahl der ausführenden Peers wächst. Fig. 3 verdeutlicht dabei, dass selbst
basierend auf einem Peer-to-Peer-Netz mit geringen Hardware-Anforderungen in der Form
von herkömmlichen PCs Simulationen von sehr großen verteilten Systemen gerechnet werden
kann.
[0046] Das im Vorangegangenen beschriebene erfindungsgemäße Verfahren weist eine Reihe von
Vorteilen auf. Insbesondere wird unter der Verwendung der Peer-to-Peer-Technologie
ein flexibles und kosteneffizientes Verfahren zur Umsetzung einer verteilten Ausführung
von Diensten geschaffen. Dabei können Peers für die Dienste-Ausführung auf einfache
Weise hinzugefügt werden, indem ein Softwarepaket auf dem entsprechenden Rechner installiert
wird, ohne dass eine weitere Konfiguration erforderlich ist. Das Verfahren ermöglicht
ferner durch die Festlegung entsprechender Regelsätze innerhalb der Dienste-Spezifikation
die Steuerung beliebiger Parameter während der Dienste-Ausführung. Beispielsweise
kann hierdurch gesteuert werden, an welchem Ort in dem Peer-to-Peer-Netz Daten gespeichert
werden oder auf Daten zugegriffen wird. Ebenso können bei der Dienste-Ausführung Kriterien
im Hinblick auf Energieeffizienz umgesetzt werden, welche für die Betreiber von Datencentern
von großer Wichtigkeit sind. Durch Festlegung entsprechender Regelsätze kann beispielsweise
erreicht werden, dass die ausgeführten Dienste auf solchen Peers durchgeführt werden,
welche eine effiziente Energieverwaltung enthalten oder welche physikalisch voneinander
getrennt sind, denn hierdurch wird bei der Dienste-Ausführung weniger Wärme produziert
und Energie zur Kühlung der Rechner eingespart.
[0047] Das im Vorangegangenen beschriebene Verfahren kann auf beliebigen Plattformen mit
heterogener Hardware sowohl basierend auf einfachen PCs als auch auf High-End-Servern
durchgeführt werden. Über den Peer-to-Peer-Mechanismus wird dabei eine dynamische
Erweiterung der zur Dienste-Ausführung verwendeten Rechner durch Hinzufügung von Peers
zum Netzwerk erreicht. Mit dem Verfahren können auch komplexe Kriterien zur Dienste-Ausführung
schnell und effizient durch die Verwendung der oben beschriebenen Index-Peers umgesetzt
werden.
[0048] Literaturverzeichnis
- [1] Stephen Boyd, Arpita Ghosh, Balaji Prabhakar und Devavrat Shah: "Gossip algorithms:
design, analysis and applications", in INFOCOM 2005, 24th Annual Joint Conference
of the IEEE Computer and Communications Societies, 13.-17. März 2005).
- [2] Rüdiger Kapitza, Holger Schmidt, Udo Bartlang und Franz J. Hauck: "A Generic Infrastructure
for Decentralised Dynamic Loading of Platform-Specific Code", in Jadwiga Indulska
and Kerry Raymond, editors, Distributed Applications and Interoperable Systems, Vol.
4531/2007 of LNCS, Seiten 323-336, Springer Berlin/Heidelberg, 2007.
- [3] Hans P. Reiser, Udo Bartlang und Franz J. Hauck: "A Reconfigurable System Architecture
for Consensus-Based Group Communication", in Si-Qing Zheng, editor, Parallel and Distributed
Computing and Systems (PDCS 2005), Seiten 680-686, ACTA Press, 2005.
1. Verfahren zur Ausführung von Diensten in einem dezentralen Datennetz mit einer Vielzahl
von Netzknoten (P1, P2, ..., P14) bei dem:
- Ressourcen-Informationen über eine erste Gruppe von einem oder mehreren ersten Netzknoten
(P1, P2, ..., P7) durch eine zweite Gruppe von einem oder mehreren zweiten Netzknoten
(P8, P9, ..., P14) bereitgestellt werden, wobei die Ressourcen-Informationen die in
den jeweiligen ersten Netzknoten (P1, P2, ..., P7) verfügbaren Ressourcen zur Ausführung
von Diensten (SE1, SE2, ..., SE6) spezifizieren;
- eine an das Datennetz gerichtete Dienste-Spezifikation (SP) von einem oder mehreren
auszuführenden Diensten (SE1, SE2, ..., SE6) innerhalb der zweiten Gruppe von zweiten
Netzknoten (P8, P9, ..., P14) derart verarbeitet wird, dass basierend auf den Ressourcen-Informationen
eine Dienstegruppe (SG) umfassend zumindest einen ersten Netzknoten (P3) zur Ausführung
des oder der Dienste (SE1, SE2, ..., SE6) gemäß der Dienste-Spezifikation (SP) ausgewählt
wird;
- an die ausgewählte Dienstegruppe (SG) die Dienste-Spezifikation (SP) übergeben wird
und der oder die Dienste (SE1, SE2, ..., SE6) gemäß der Dienste-Spezifikation durch
die Dienstegruppe (SG) ausgeführt werden.
2. Verfahren nach Anspruch 1, bei dem die Ressourcen-Informationen innerhalb der zweiten
Gruppe von zweiten Netzknoten (P8, P9, ..., P14) in einer oder mehreren Datenbanken
(DB) abgelegt sind, wobei über eine Datenbank-Abfrage (DB) die an das Datennetz gerichtete
Dienste-Spezifikation verarbeitet wird.
3. Verfahren nach Anspruch 2, bei dem das oder die Datenbanken (DB) eine Peer-to-Peer-Datenbank
umfassen.
4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Ressourcen-Informationen
statische und/oder dynamische Eigenschaften der jeweiligen ersten Netzknoten (P1,
P2, ..., P7), insbesondere im Hinblick auf in den jeweiligen ersten Netzknoten (P1,
P2, ..., P7) verfügbaren Speicherplatz und/oder verfügbare Rechenleistung und/oder
verfügbare Daten und/oder verfügbare Programme, beschreiben.
5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Dienste-Spezifikation
(SP) eine Beschreibung der durch den oder die Dienste (SE1, SE2, ..., SE6) durchzuführende
Aufgabe und einen Regelsatz enthält, der eine oder mehreren Anforderungen an die zur
Ausführung des oder der Dienste (SE1, SE2, ..., SE6) zu verwendende Dienstegruppe
(SG) enthält.
6. Verfahren nach Anspruch 5, bei dem der Regelsatz derart ausgestaltet ist, dass die
Ausführung des oder der Dienste (SE1, SE2, ..., SE6) wenig Energie verbraucht.
7. Verfahren nach Anspruch 6, bei dem bei der Ausführung des oder der Dienste (SE1, SE2,
..., SE6) erste Netzknoten (P1, P2, ..., P7) mit physikalisch entfernt voneinander
angeordneter Hardware und/oder erste Netzknoten mit geringem Energieverbrauch bevorzugt
eingesetzt werden.
8. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die ausgewählte Dienstegruppe
(SG) mehrere erste Netzknoten (P2, P3, P4) umfasst, welche zumindest einen Koordinatorknoten
(P2) zur Koordinierung der Ausführung des oder der Dienste (SE1, SE2, ..., SE6) gemäß
der Dienste-Spezifikation (SP) und zumindest einen ausführenden Netzknoten (P3) zur
Ausführung des oder der Dienste (SE1, SE2, ..., SE6) beinhalten.
9. Verfahren nach Anspruch 8, bei dem die ausgewählte Dienstegruppe (SG) ferner zumindest
einen Überwachungsknoten (P4) umfasst, der die Ausführung des oder der Dienste (SE1,
SE2, ..., SE6) überwacht und die Aufgabe eines Koordinatorknotens (P2) oder eines
ausführenden Netzknotens (P3) übernehmen kann, insbesondere bei Ausfall eines Koordinatorknotens
(P2) oder eines ausführenden Netzknotens (P3).
10. Verfahren nach Anspruch 9, bei dem in dem zumindest einen Überwachungsknoten (P4)
in regelmäßigen Abständen der aktuelle Rechenzustand des zumindest einen Koordinatorknotens
(P2) und/oder des zumindest einen ausführenden Netzknotens (P3) hinterlegt wird.
11. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Dienstegruppe (SG)
bei der Ausführung des oder der Dienste (SE1, SE2, ..., SE6) gemäß der Dienste-Spezifikation
(SP) basierend auf einem oder mehreren Kriterien dynamisch veränderbar ist, wobei
insbesondere die Ausführung eines Dienstes (SE1, SE2, ..., SE6) von einem ausführenden
Netzknoten (P3) auf einen anderen Netzknoten übertragen wird, wenn der andere Netzknoten
gemäß dem oder den Kriterien besser zur Ausführung des Dienstes (SE1, SE2, ..., SE6)
geeignet ist.
12. Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Datennetz auf einem
Peer-to-Peer-Protokoll beruht, insbesondere auf einem Chord-Ring, auf dem die ersten
und zweiten Netzknoten (P1, P2, ..., P14) des Datennetzes angeordnet sind.
13. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Ressourcen-Informationen
in der zweiten Gruppe von zweiten Netzknoten (P8, P9, ..., P14) über ein Protokoll
verteilt werden, insbesondere über ein auf Gossip basierendes Protokoll.
14. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Dienste-Spezifikation
(SP) über eine Web-Service-Schnittstelle (WSI) an die zweite Gruppe von zweiten Netzknoten
(P8, P9, ..., P14) gerichtet wird.
15. Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein zur Ausführung eines
Dienstes (SE1, SE2, ..., SE6) in der ausgewählten Dienstegruppe (SG) bestimmter Netzknoten
(P3) Software-Code zur Ausführung des Dienstes (SE1, SE2, ..., SE6) von einem anderen
Netzknoten lädt, falls er keinen Software-Code zur Ausführung des Dienstes (SE1, SE2,
..., SE6) enthält.
16. Verfahren nach einem der vorhergehenden Ansprüche, bei dem die im Datennetz ausgeführten
Dienste (SE1, SE2, ..., SE6) OSGi-Services darstellen.
17. Dezentrales Datennetz zur Ausführung von Diensten, umfassend eine Vielzahl von Netzknoten
(P1, P2, ..., P14), wobei eine erste Gruppe von ersten Netzknoten (P1, P2, ..., P7)
und eine zweite Gruppe von zweiten Netzknoten (P8, P9, ..., P14) vorgesehen sind und
im Betrieb des Datennetzes:
- Ressourcen-Informationen über die erste Gruppe von ersten Netzknoten (P1, P2, ...,
P7) durch die zweite Gruppe von zweiten Netzknoten (P8, P9, ..., P14) bereitgestellt
werden, wobei die Ressourcen-Informationen die in den jeweiligen ersten Netzknoten
(P1, P2, ..., P7) verfügbaren Ressourcen zur Ausführung von Diensten (SE1, SE2, ...,
SE6) spezifizieren;
- eine an das Datennetz gerichtete Dienste-Spezifikation (SP) von einem oder mehreren
auszuführenden Diensten (SE1, SE2, ..., SE6) innerhalb der zweiten Gruppe von zweiten
Netzknoten (P8, P9, ..., P14) derart verarbeitet wird, dass basierend auf den Ressourcen-Informationen
eine Dienstegruppe (SG) umfassend zumindest einen ersten Netzknoten (P2, P3, P4) zur
Ausführung des oder der Dienste (SE1, SE2, ..., SE6) gemäß der Dienste-Spezifikation
(SP) ausgewählt wird;
- an die ausgewählte Dienstegruppe (SG) die Dienste-Spezifikation übergeben wird und
der oder die Dienste (SE1, SE2, ..., SE6) gemäß der Dienste-Spezifikation durch die
Dienstegruppe (SG) ausgeführt werden.
18. Datennetz nach Anspruch 17, welches derart ausgestaltet ist, dass in dem Datennetz
ein Verfahren nach einem der Ansprüche 1 bis 16 durchführbar ist.