DE102020129195A1

DE102020129195A1 - Vereinheitlichtes programmiermodul für eine funktion-als-ein-dienst-berechnung

Info

Publication number: DE102020129195A1
Application number: DE102020129195.7A
Authority: DE
Inventors: Sara Baghsorkhi; Mohammad R. Haghighat
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2019-12-20
Filing date: 2020-11-05
Publication date: 2021-06-24
Also published as: CN113010235A; KR20210080172A; US20200137163A1; JP2021099782A

Abstract

Systeme, Vorrichtungen und Verfahren können Technologie bereitstellen, die einen generischen Cloud-Dienstaufruf in einer Anwendung erkennt, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind. Die Technologie kann auch eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit der ersten Cloud-Plattform auswählen und automatisch einen für die erste Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes erzeugen. Bei einem Beispiel ordnet die Technologie den Cloud-Dienstaufruf auch dem für die erste Plattform spezifischen Dienstaufruf zu. Zusätzlich kann die Technologie den Cloud-Dienstaufruf zu einer zweiten Cloud-Plattform migrieren, ohne den generischen Cloud-Dienstaufruf umzuschreiben.

Description

TECHNISCHES GEBIET
Ausführungsformen betreffen allgemein Anwendungsprogrammierschnittstellen (APIs). Ausführungsformen betreffen insbesondere ein vereinheitlichtes Programmiermodell für eine Funktion-als-ein-Dienst(FaaS)-Berechnung.
HINTERGRUND
Wenn eine Anwendung auf einer Cloud-Recheninfrastruktur („Cloud“) installiert wird, werden die Anwendungsprogrammierschnittstellen (APIs) und Protokolle, die innerhalb der Anwendung verwendet werden, typischerweise eng mit einer spezifischen Plattform (beispielsweise von einem spezifischen Cloud-Anbieter betrieben) gekoppelt. Weil die Landschaft der Cloud-Anbieter wächst und heterogener wird, kann diese enge Kopplung Herausforderungen in Bezug auf Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit hervorrufen. Falls beispielsweise eine günstigere Dienstplattform verfügbar wird, nachdem eine Cloud-Anwendung installiert wurde (oder während der Installation), kann der Zusatzaufwand des Migrierens der Cloud-Anwendung zur günstigeren Dienstplattform die Vorteile der neuen Dienstplattform überwiegen. Eine solche Situation kann in einer Funktion-als-ein-Dienst (FaaS)-Architektur sogar noch ausgeprägter werden, wobei ein API-Endpunkt für einen einzigen Zweck auf einer Cloud bereitgestellt wird, um Codeausführungsanforderungen für einen verhältnismäßig kurzen Zeitraum zu empfangen und auszuführen.
Figurenliste
Die verschiedenen Vorteile der Ausführungsformen werden Fachleuten beim Lesen der folgenden Beschreibung und der anliegenden Ansprüche und mit Bezug auf die folgenden Zeichnungen verständlich werden. Es zeigen:

1 ein Blockdiagramm eines Beispiels einer heterogenen Cloud gemäß einer Ausführungsform,
2 ein Blockdiagramm eines Beispiels des Portierens einer Cloud-Anwendung auf ein oder mehrere Module, die auf einer heterogenen Cloud laufen, gemäß einer Ausführungsform,
3 ein Blockdiagramm eines Beispiels einer portierten Cloud-Anwendung auf einer heterogenen Cloud-Rechenarchitektur gemäß einer Ausführungsform,
4 ein Flussdiagramm eines Beispiels eines Verfahrens zum Portieren einer Anwendung auf eine heterogene Cloud gemäß einer Ausführungsform,
5 ein Flussdiagramm eines Beispiels eines detaillierteren Verfahrens zum Portieren einer Anwendung auf eine heterogene Cloud gemäß einer Ausführungsform,
6A ein Blockdiagramm eines Beispiels einer inkrementellen Migration einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform,
6B ein Blockdiagramm eines Beispiels einer abgeschlossenen Migration einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform,
7 ein Flussdiagramm eines Beispiels eines Verfahrens zum Migrieren einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform,
8 ein Flussdiagramm eines Beispiels eines Verfahrens zum Behandeln von Cloud-Dienstaufrufen gemäß einer Ausführungsform,
9A ein Flussdiagramm eines Beispiels eines Verfahrens zum Übertragen von Zustandsdaten zwischen Cloud-Plattformen gemäß einer Ausführungsform,
9B ein Flussdiagramm eines Beispiels eines detaillierteren Verfahrens zum Behandeln von Cloud-Dienstaufrufen gemäß einer Ausführungsform,
10 ein Blockdiagramm eines Beispiels eines Rechensystems mit erhöhter Leistungsfähigkeit gemäß einer Ausführungsform,
11 eine Darstellung eines Beispiels einer Halbleitervorrichtung gemäß einer Ausführungsform,
12 ein Blockdiagramm eines Beispiels eines Prozessors gemäß einer Ausführungsform und
13 ein Blockdiagramm eines Beispiels eines Multiprozessor-basierten Rechensystems gemäß einer Ausführungsform.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
1 zeigt eine heterogene Cloud 20, bei der eine Cloud-portierbare Anwendung 22 einen Speicherdienst, einen Natürliche-Sprachverarbeitung(NLP)-Dienst, einen Datenbankdienst, einen Authentifizierungsdienst usw. während des Betriebs verwendet. Gemäß einer Ausführungsform wird ein vereinheitlichtes Programmiermodell 28 (28a - 28d) beispielsweise in der Art von ONEAPI verwendet, um die Anwendung 22 zur Ausführung über die heterogene Cloud 20 zu konfigurieren, die sehr verschiedene Typen von Hardware-Ressourcen (beispielsweise Host-Prozessoren, Graphikprozessoren, feldprogrammierbare Gate-Arrays/FPGAs, Beschleuniger für spezielle Zwecke usw.) aufweisen kann.
Beim dargestellten Beispiel wird eine Cloud-Plattform automatisch aus einem Satz heterogener Speicherdienstplattformen 24 (24a, 24b) ausgewählt, um den Speicherdienst bereitzustellen. Beispielsweise könnte eine erste Speicherdienstplattform 24a („1. Speicherdienstplattform“) eine AMAZON-SIMPLE-STORAGE-SERVICE(S3)-Plattform sein, während eine zweite Speicherdienstplattform 24b („n-te Speicherdienstplattform“) eine GOOGLE-CLOUD-STORAGE-Plattform sein kann. Demgemäß kann der Speicherdienst von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die Speicherdienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine Speicherdienstkomponente 28a zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener Speicherdienstplattformen 24 auf.
Wie in weiteren Einzelheiten erörtert wird, kann die Speicherdienstkomponente 28a transparente Migrationen der Anwendung 22 (beispielsweise aus der Perspektive des Anwendungsbenutzers) zwischen den Cloud-Plattformen im Satz heterogener Speicherdienstplattformen 24 auf der Grundlage von Änderungen in verfügbaren Speicherdiensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22 ermöglichen. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit verbessern.
Eine Cloud-Plattform kann auch automatisch aus einem Satz heterogener NLP-Dienstplattformen 30 (30a, 30b) ausgewählt werden, um den NLP-Dienst bereitzustellen. Beispielsweise kann eine erste NLP-Dienstplattform 30a („1. Übersetzungsplattform“) eine AMAZON-TRANSLATE-Plattform sein, während eine zweite NLP-Dienstplattform 30b („m-te Übersetzungsplattform“) eine GOOGLE-TRANSLATE-Plattform sein könnte. Demgemäß kann der NLP-Dienst auch von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die NLP-Dienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine NLP-Dienstkomponente 28b zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener NLP-Dienstplattformen 30 auf.
Demgemäß kann die NLP-Dienstkomponente 28b transparente Migrationen der Anwendung 22 (beispielsweise aus der Perspektive des Anwendungsbenutzers) zwischen den Cloud-Plattformen im Satz heterogener NLP-Dienstplattformen 30 auf der Grundlage von Änderungen in verfügbaren NLP-Diensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22 ermöglichen. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit weiter verbessern.
Zusätzlich kann eine Cloud-Plattform automatisch aus einem Satz heterogener Datenbank-Dienstplattformen 32 (32a - 32d) ausgewählt werden, um den Datenbankdienst bereitzustellen. Beispielsweise könnte eine erste Datenbank-Dienstplattform 32a („Datenbankplattform A“) eine AMAZON-DYNAMODB-Plattform sein, kann eine zweite Datenbank-Dienstplattform 32b („Datenbankplattform i“) eine AMAZON-AURORA-Plattform sein, könnte eine dritte Datenbank-Dienstplattform 32c („Datenbankplattform i+1“) eine GOOGLE-CLOUD-FIRESTORE-Plattform sein und kann eine vierte Datenbank-Dienstplattform 32d („Datenbankplattform N“) eine GOOGLE-CLOUD-SQL-Plattform sein. Demgemäß kann der Datenbankdienst von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die Datenbankdienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine Datenbank-Dienstkomponente 28c zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener Datenbank-Dienstplattformen 32 auf.
Die Datenbank-Dienstkomponente 28c ermöglicht transparente Migrationen der Anwendung 22 zwischen den Cloud-Plattformen im Satz heterogener Datenbank-Dienstplattformen 32 auf der Grundlage von Änderungen in verfügbaren Datenbankdiensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit weiter verbessern.
Überdies kann eine Cloud-Plattform automatisch aus einem Satz heterogener Authentifizierungsdienstplattformen 34 (34a, 34b) ausgewählt werden, um den Authentifizierungsdienst bereitzustellen. Beispielsweise kann eine erste Authentifizierungsdienstplattform 34a („Authentifizierungsplattform #1“) eine AMAZON-CONGNITO-Plattform sein, während eine zweite Authentifizierungsdienstplattform 34b („Authentifizierungsplattform #M“) eine GOOGLE-FIREBASE-Plattform sein könnte. Demgemäß kann der Authentifizierungsdienst von verschiedenen Cloud-Anbietern/Verkäufern erhalten werden, die verschiedene plattformspezifische Parameter aufweisen, um die Authentifizierungsdienstunterstützung bereitzustellen. Gemäß einer Ausführungsform weist das vereinheitlichte Programmiermodell 28 eine Authentifizierungsdienstkomponente 28d zur Erleichterung der Konfiguration der Anwendung 22 auf der ausgewählten Cloud-Plattform im Satz heterogener Authentifizierungsdienstplattformen 34 auf.
Bei einem Beispiel ermöglicht die Authentifizierungsdienstkomponente 28d transparente Migrationen der Anwendung 22 zwischen den Cloud-Plattformen im Satz heterogener Authentifizierungsdienstplattformen 34 auf der Grundlage von Änderungen in verfügbaren Authentifizierungsdiensten (beispielsweise Merkmale, Preise) und/oder Änderungen in Leistungsfähigkeitsrandbedingungen der Anwendung 22. Ein solcher Ansatz kann die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit weiter verbessern.
FaaS ist ein ereignisorientiertes, hochskalierbares Computercode-Ausführungsmodell, das typischerweise einen API-Endpunkt für einen einzigen Zweck auf einer Cloud-Recheninfrastruktur bereitstellt, um die Codeausführungsanforderungen für einen verhältnismäßig kurzen Zeitraum zu empfangen und auszuführen. Diese Codeausführungsanforderungen und/oder Ausführungen angeforderten Codes werden verschiedenartig und üblicherweise als Lambdas, Funktionen, Aktionen und/oder Ausführung-bis-zum-Abschluss-Prozeduren bezeichnet. Der erläuterte Ansatz zur Portierung von Teilen der Anwendung 22 auf Cloud-Plattformen und zum Migrieren von Teilen der Anwendung 22 zwischen Cloud-Plattformen kann infolge der transienten Natur der Verknüpfungen zwischen Funktionen und der zugrunde liegenden Hardware in einer FaaS-Umgebung besonders vorteilhaft sein.
2 zeigt die Portierung einer Cloud-portierbaren Anwendung 40 (beispielsweise einschließlich FaaS-Lambdas, -Funktionen, -Aktionen und/oder - Ausführung-bis-zum-Abschluss-Prozeduren) auf eine heterogene Cloud 42 (42a - 42c), die eine erste Cloud-Plattform 42a (beispielsweise GOOGLE-Cloud), eine zweite Cloud-Plattform 42b (beispielsweise MICROSOFT-Cloud) und eine dritte Cloud-Plattform 42c (beispielsweise AMAZON-Cloud) umfasst. Beim erläuterten Beispiel verwendet ein Abfertiger 44 („vereinheitlichter dynamischer Cloud-Abfertiger und Cloud-Übertragungs-Laufzeit“) einen ersten Modulmanager 46 zur Erzeugung eines ersten portierten Moduls 48 für die erste Cloud-Plattform 42a und einen zweiten Modulmanager 50 zur Erzeugung eines zweiten portierten Moduls 52 für die zweite Cloud-Plattform 42b. Zur Installationszeit mustert der Abfertiger 44 die verfügbaren Cloud-Dienste/Verkäufer und entscheidet auf der Grundlage von durch die Anwendung 40 geforderten Anforderungen des Dienstes, wie beispielsweise Skalierbarkeit und Lese-/Schreibbandbreite, welcher Ressource in der Cloud 42 der Dienst zugeordnet werden sollte. Zu dieser Zeit können spezialisierter Code/spezialisierte Aufrufe für jeden generischen API-Aufruf erzeugt werden, so dass sie mit der API und Konsistenzprotokollen des Verkäufers übereinstimmen/diesen genügen.
3 zeigt eine portierte Cloud-Anwendung. Beim dargestellten Beispiel werden Kommunikationen zwischen dem ersten portierten Modul 48 und der ersten Cloud-Plattform 42a, zwischen dem zweiten portierten Modul 52 und der zweiten Cloud-Plattform 52 und zwischen dem ersten portierten Modul 48 und dem zweiten portierten Modul 52 eingerichtet. Abgesehen von Rechenressourcenanforderungs-/Randbedingungserwägungen können auch Faktoren in der Art des Dienstpreises vom Abfertiger 44 berücksichtigt werden (beispielsweise durch Installieren eines dynamischen Bieterschemas zwischen Cloud-Anbietern).
4 zeigt ein Verfahren 60 zum Portieren einer Anwendung auf eine heterogene Cloud. Das Verfahren 60 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 ( 2 und 3), wie bereits erörtert. Insbesondere kann das Verfahren 60 in einem oder mehreren Modulen als ein Satz in einem maschinen- oder computerlesbaren Speichermedium in der Art eines Direktzugriffsspeichers (RAMs), Nurlesespeichers (ROMs), programmierbaren ROMs (PROMs), Firmware, Flash-Speichers usw., in konfigurierbarer Logik in der Art beispielsweise programmierbarer Logik-Arrays (PLAs), FPGAs, komplexer programmierbarer Logikvorrichtungen (CPLDs), in Festfunktionalitäts-Logikhardware unter Verwendung von Schaltungstechnologie in der Art beispielsweise anwendungsspezifischer integrierter Schaltungen (ASIC), komplementärer MetallOxid-Halbleiter(CMOS)- oder Transistor-Transistor-Logik(TTL)-Technologie oder einer Kombination davon gespeicherter Logikbefehle implementiert werden.
Beispielsweise kann Computerprogrammcode zur Ausführung der im Verfahren 60 dargestellten Operationen in einer Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache in der Art von JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen in der Art der Programmiersprache „C“ oder ähnlichen Programmiersprachen geschrieben werden. Zusätzlich könnten Logikbefehle Assembler-Befehle, ISA-Befehle, Maschinenbefehle, maschinenabhängige Befehle, Mikrocode, Zustandsfestlegungsdaten, Konfigurationsdaten für integrierte Schaltungsanordnungen, Zustandsinformationen, die elektronische Schaltungsanordnungen und/oder andere Strukturkomponenten, die für Hardware nativ sind (beispielsweise Host-Prozessor, Zentralverarbeitungseinheit/CPU, Mikrosteuereinrichtung usw.) personalisieren, einschließen.
Der dargestellte Verarbeitungsblock 62 erfasst einen generischen Cloud-Dienstaufruf in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind. Falls sich der Cloud-Dienstaufruf auf einen Datenbankdienst bezieht, könnte der Aufruf beispielsweise die Erzeugung einer Schlüsselwert-Datenbanktabelle, das Hinzufügen von Zeilen/Spalten, das Entfernen von Bestandteilen, das Initiieren von Anfragen, das Aktualisieren von Anfragen usw. unter Verwendung generischer API-Aufrufe, ohne verkäuferspezifische APIs oder Module zu spezifizieren, aufweisen. Eine erste Cloud-Plattform wird in Block 64 auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen (beispielsweise Skalierbarkeit und/oder Lese-/Schreibbandbreitenanforderungen) und eines ersten Parametersatzes (beispielsweise verkäuferspezifische APIs und/oder Module), die der ersten Cloud-Plattform zugeordnet sind, ausgewählt.
Block 66 sieht die automatische Erzeugung eines für eine erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes vor. Bei einem Beispiel wird in Block 66 eine Kombination von Compileranalyse zur Erkennung von Rückwärts/Vorwärts-Codeabschnitten in Bezug auf einen generischen Aufruf/einen generischen Aufruf umgebend - in der Art eines Ausnahmebehandlungscodes und einer Anfrageantwort-Nachverarbeitung - und Serien spezialisierter Codebestandteile, die entsprechend jedem Verkäufer für die API-Aufrufe vorkompiliert/erzeugt werden, verwendet. Gemäß einer Ausführungsform bildet Block 68 den Cloud-Dienstaufruf auf den für die erste Plattform spezifischen Dienstaufruf ab. Das dargestellte Verfahren 60 erhöht daher die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit durch Ermöglichen, dass eine Anwendung mit unspezifizierten plattformspezifischen Parametern auf eine Cloud-Plattform portiert wird.
5 zeigt ein detaillierteres Verfahren 70 zum Portieren einer Anwendung auf eine heterogene Cloud. Das Verfahren 70 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2 und 3), wie bereits erörtert. Insbesondere kann das Verfahren 70 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
Der dargestellte Verarbeitungsblock 72 sieht die Bestimmung, ob die Anwendung generische Cloud-Dienst-API-Aufrufe enthält, vor. Falls dies nicht der Fall ist, kann das Verfahren 70 enden. Andernfalls greift Block 74 eine Klasse existierender Cloud-Dienste wie beispielsweise Datenbankdienste heraus/wählt diese aus. In Block 76 wird festgestellt, ob es eine durch die Anwendung für den Dienst festgelegte Leistungsfähigkeitsanforderung oder ein dafür festgelegtes Kostenbudget gibt. Falls dies der Fall ist, können in Block 78 dementsprechend minimale („min“) Leistungsfähigkeitsanforderungen (beispielsweise Lese-/Schreibbandbreite für Datenbanken) festgelegt werden. Block 80 sieht dann das Mustern von Cloud-Anbietern für die Dienste mit übereinstimmenden Leistungsfähigkeitsprofilen und Kostenangaben vor. Es kann dann in Block 84 festgestellt werden, ob ein Anbieter mit einem übereinstimmenden Dienst/Profil/Budget gefunden wurde. Falls dies der Fall ist, stellt Block 86 spezialisierten Code/spezialisierte Aufrufe zusammen, um die generischen Dienst-API-Aufrufe zu ersetzen, um den API- und Konsistenzprotokollen des Verkäufers zu entsprechen. Block 86 kann eine Kombination von Compileranalyse und einer Reihe von Codeabschnitten verwenden, die entsprechend jedem Verkäufer für die API-Aufrufe vorkompiliert/erzeugt werden. Das dargestellte Verfahren 70 kehrt dann zu Block 72 zurück.
Falls in Block 76 keine Leistungsfähigkeitsanforderungen oder kein Kostenbudget erkannt werden, verwendet der dargestellte Block 82 Standardschwellenwerte und wird das Verfahren 70 in Block 80 fortgesetzt. Falls zusätzlich in Block 84 keine Anbieter gefunden werden, stellt Block 88 die Schwellenwerte (beispielsweise mit Rückmeldung von der Anwendung und/oder vom Benutzer oder ohne diese) wieder ein. Das Verfahren 70 kann dann zu Block 80 zurückkehren. Das Verfahren 70 erhöht daher die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit durch Ermöglichen, dass eine Anwendung mit unspezifizierten plattformspezifischen Parametern auf eine Cloud-Plattform portiert wird.
6A zeigt, dass, wenn sich die Verfügbarkeit des Dienstes, Anforderungen der Anwendung oder sogar der Preis während des Lebenszyklus einer Anwendung ändert, der dargestellte Abfertiger 44 in der Lage ist, eine vollständige Anwendung oder einen Teil davon allmählich von einem Cloud-Anbieter zu einem anderen zu migrieren, wobei nur eine geringe oder minimale Unterbrechung der Anwendungsausführung auftritt. Beim dargestellten Beispiel verwendet der Abfertiger 44 einen dritten Modulmanager 90 für die Erzeugung eines dritten portierten Moduls 92 für die dritte Cloud-Plattform 42c, wodurch schließlich die zweite Cloud-Plattform 42b ersetzt wird. Während der Laufzeit und während Zustandsdaten von der zweiten Cloud-Plattform 42b zur dritten Cloud-Plattform 42c übertragen werden, wird das dargestellte dritte portierte Modul 92 als „kalt“ angesehen. Wie in weiteren Einzelheiten erörtert wird, kann die Übertragung von Zustandsdaten in einer Weise verfolgt werden, welche es ermöglicht, dass die Migration im Wesentlichen für den Anwendungsbenutzer transparent ist.
6B zeigt eine abgeschlossene Migration. Beim erläuterten Beispiel werden Kommunikationen zwischen dem dritten portierten Modul 92 und der dritten Cloud-Plattform 42c und zwischen dem dritten portierten Modul 92 und dem ersten portierten Modul 48 eingerichtet. Zusätzlich ist die Übertragung interner Zustandsdaten abgeschlossen, so dass das dritte portierte Modul 92 nicht mehr als kalt angesehen wird.
7 zeigt ein Verfahren 100 zum Migrieren einer Anwendung zwischen Cloud-Plattformen gemäß einer Ausführungsform. Das Verfahren 100 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 100 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
Der dargestellte Verarbeitungsblock 102 wählt eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen (beispielsweise Skalierbarkeits- und/oder Lese-/Schreibbandbreitenanforderungen) und eines zweiten Parametersatzes (beispielsweise verkäuferspezifischer APIs und/oder Module) in Zusammenhang mit der zweiten Plattform aus. Block 104 kann automatisch einen zweiten plattformspezifischen Aufruf auf der Grundlage des generischen Cloud-Dienstaufrufs und des zweiten Parametersatzes erzeugen. Gemäß einer Ausführungsform wird in Block 104 eine Kombination von Compileranalyse und einer Reihe von Codeabschnitten, die für die jedem Dienstanbieter/Verkäufer entsprechenden API-Aufrufe vorkompiliert/erzeugt wurden, verwendet. Der generische Cloud-Dienstaufruf kann in Block 106 dem zweiten plattformspezifischen Dienstaufruf zugeordnet werden. Block 108 führt eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform aus, wobei der dargestellte Block 110 die Übertragung über eine Bitmap verfolgt. Gemäß einer Ausführungsform entspricht jedes Bit der Bitmap einem Segment, einem Byte und/oder einem Teil (beispielsweise einer Untermenge) des internen Zustands der aktuellen (beispielsweise „alten“) Cloud-Plattform. Demgemäß kann die Bitmap aktualisiert werden, wenn die verschiedenen Teilmengen des internen Zustands zur nächsten (beispielsweise „zweiten“ oder „neuen“) Cloud-Plattform übertragen werden (beispielsweise entweder durch eine direkte Kopie durch den Abfertiger/die Laufzeit oder Schreiboperationen der Anwendung). Das dargestellte Verfahren 100 erhöht daher die Leistungsfähigkeit, Skalierbarkeit, Effizienz und/oder Kostenwirksamkeit durch Ermöglichen, dass eine Anwendung mit unspezifizierten plattformspezifischen Parametern transparent zwischen Cloud-Plattformen migriert wird.
8 zeigt ein Verfahren 120 zur Behandlung von Cloud-Dienstaufrufen. Das Verfahren 120 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 120 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
Der dargestellte Verarbeitungsblock 122 sieht das Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs vor. Wie bereits erwähnt, können plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert (beispielsweise nicht darin vorhanden) sein. Gemäß einer Ausführungsform gibt Block 124 selektiv ansprechend auf die Laufzeitinstanz den für die erste Plattform spezifischen Dienstaufruf und/oder den für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Status der Übertragung aus. Falls der Cloud-Dienstaufruf beispielsweise nur Teilmengen der Zustandsdaten betrifft, die bereits zur zweiten (beispielsweise neuen) Cloud-Plattform übertragen wurden, kann Block 124 sowohl den für die erste als auch für die zweite Plattform spezifischen Dienstaufruf ausgeben. Falls der Cloud-Dienstaufruf dagegen Teilmengen der Zustandsdaten betrifft, die noch nicht zur zweiten Cloud-Plattform übertragen worden sind, kann Block 124 nur den für die erste Plattform spezifischen Dienstaufruf (beispielsweise an die erste Cloud-Plattform) ausgeben. Ein solcher Ansatz kann gewährleisten, dass die Migration inkrementell und transparent stattfindet.
9A zeigt ein Verfahren 130 zum Übertragen von Zustandsdaten zwischen Cloud-Plattformen. Das Verfahren 130 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 (2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 130 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
Der dargestellte Verarbeitungsblock 132 erzeugt eine Bitmap, wobei jedes Bit ein Segment, ein Byte oder einen Teil des internen Zustands des aktuellen/alten Dienstverkäufers (beispielsweise Cloud-Plattform) repräsentiert. Gemäß einer Ausführungsform kopiert und überträgt Block 134 jedes interne Zustandssegment des alten Verkäufers zum internen Zustand des neuen Verkäufers. Zusätzlich kann Block 134 für jedes übertragene Byte/Segment das entsprechende Bit in der Bitmap festlegen, um anzugeben, dass die Übertragung abgeschlossen ist. In Block 136 kann festgestellt werden, ob alle Bits der Bitmap gesetzt wurden. Falls dies nicht der Fall ist, kehrt das dargestellte Verfahren 130 zu Block 134 zurück. Andernfalls trennt sich Block 138 vom alten Verkäufer und lässt sich ganz mit dem neuen Verkäufer ein, und das Verfahren 130 endet.
9B zeigt ein detaillierteres Verfahren 140 zur Behandlung von Cloud-Dienstaufrufen. Das Verfahren 140 kann generell in einer Abfertigungs- und/oder Laufzeitmaschine implementiert werden, wie beispielsweise dem Abfertiger 44 ( 2, 3, 6A und 6B), wie bereits erörtert. Insbesondere kann das Verfahren 140 in einem oder mehreren Modulen als ein Satz von Logikbefehlen, die in einem maschinen- oder computerlesbaren Speichermedium gespeichert sind, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in einer konfigurierbaren Logik in der Art von beispielsweise PLAs, FPGAs, CPLDs, in Festfunktionalitäts-Logikhardware unter Verwendung einer Schaltungstechnologie in der Art beispielsweise einer ASIC-, CMOS- oder TTL-Technologie oder einer Kombination davon implementiert werden.
Der dargestellte Verarbeitungsblock 142 erkennt einen neuen Dienstaufruf (beispielsweise Instanz des Cloud-Dienstaufrufs) von der Anwendung. Gemäß einer Ausführungsform wird in Block 144 festgestellt, ob die neue Anforderung nur Teilmengen des internen Zustands liest, wobei Bits für die vollständige Übertragung festgelegt sind. Falls dies der Fall ist, kann die Anforderung in Block 146 erneut sowohl an den alten als auch an den neuen Verkäufer (beispielsweise Cloud-Plattformen) erteilt werden (beispielsweise durch plattformspezifische Dienstaufrufe ausgeführt). Bei einem Beispiel stellt Block 148 dann fest, ob die neue Anforderung nur in Teilmengen des internen Zustands schreibt, wobei Bits für die vollständige Übertragung festgelegt sind. Falls dies der Fall ist, endet die Verarbeitung der Anforderung in Block 150. Falls in Block 148 festgestellt wird, dass die neue Anforderung nicht nur in Teilmengen des internen Zustands schreibt, wobei Bits für die vollständige Übertragung festgelegt sind, legt Block 152 die Übertragung-vollständig-Bits für die durch die Anforderung aktualisierte Teilmenge fest.
Falls in Block 144 festgestellt wird, dass die neue Anforderung nicht nur Teilmengen des internen Zustands, wobei Bits für eine vollständige Übertragung festgelegt sind, liest, erteilt der dargestellte Block 154 die Anforderung nur an den alten Verkäufer (gibt sie beispielsweise durch einen plattformspezifischen Dienstaufruf aus). Zusätzlich kann in Block 156 festgestellt werden, ob die neue Anforderung in jegliche der Teilmengen des internen Zustands schreibt, bei denen Bits für eine vollständige Übertragung festgelegt sind. Falls dies der Fall ist, löscht Block 158 die Übertragung-vollständig-Bits für die durch die Anforderung aktualisierte Teilmenge des internen Zustands/setzt diese zurück. Andernfalls wird die Verarbeitung der Anforderung in Block 160 abgeschlossen.
10 zeigt ein Rechensystem 170 mit erhöhter Leistungsfähigkeit. Das System 170 kann allgemein Teil einer elektronischen Vorrichtung/Plattform sein, die Rechenfunktionalität (beispielsweise persönlicher digitaler Assistent/PDA, Notebookcomputer, Tabletcomputer, konvertibles Tablet, Server), Kommunikationsfunktionalität (beispielsweise Smartphone), Bildgebungsfunktionalität (beispielsweise Kamera, Camcorder), Medienwiedergabefunktionalität (beispielsweise Smart-Fernsehgerät/TV), tragbare Funktionalität (beispielsweise Uhr, Brille, am Kopf getragene Vorrichtung, am Fuß getragene Vorrichtung, Schmuck), Fahrzeugfunktionalität (beispielsweise PKW, Lastwagen, Motorrad), Roboterfunktionalität (beispielsweise autonomer Roboter) usw. oder eine Kombination davon aufweist. Beim dargestellten Beispiel weist das System 170 einen Host-Prozessor 172 mit einer integrierten Speichersteuereinrichtung (IMC) 174, die mit einem Systemspeicher 176 gekoppelt ist, auf.
Das dargestellte System 170 weist auch ein Eingabe-/Ausgabe(EA)-Modul 178 auf, das zusammen mit dem Host-Prozessor 172 und einem Grafikprozessor 180 auf einem Halbleiter-Die 182 als System-on-Chip (SoC) implementiert ist. Das dargestellte EA-Modul 178 kommuniziert beispielsweise mit einer Anzeige 184 (beispielsweise Touchscreen-, Flüssigkristallanzeige/LCD-, Leuchtdioden/LED-Anzeige), einer Netzsteuereinrichtung 186 (beispielsweise festverdrahtet und/oder drahtlos) und einem Massenspeicher 188 (beispielsweise Festplattenlaufwerk/HDD, optische Scheibe, Halbleiterlaufwerk/SSD, Flash-Speicher).
Gemäß einer Ausführungsform führen der Host-Prozessor 172, der Grafikprozessor 180 und/oder das EA-Modul 178 aus dem Systemspeicher 176 und/oder dem Massenspeicher 188 abgerufene Programmbefehle 190 aus, um einen oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B), wie bereits erörtert, auszuführen. Demgemäß kann die Ausführung der dargestellten Befehle 190 das Rechensystem 170 veranlassen, einen Cloud-Dienstaufruf in einer Anwendung zu erkennen, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, und eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und einem ersten Parametersatz in Zusammenhang mit der ersten Cloud-Plattform auszuwählen. Die Ausführung der Befehle 190 kann das Rechensystem 170 auch veranlassen, automatisch einen für die erste Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes zu erzeugen.
Überdies kann die Ausführung der Befehle 190 das Rechensystem 170 veranlassen, eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform auszuwählen und automatisch einen für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes zu erzeugen. Das dargestellte Rechensystem 170 weist daher zumindest in dem Maße eine erhöhte Leistungsfähigkeit auf, dass es Anwendungen mit generischen Cloud-Dienstaufrufen auf Cloud-Plattformen portiert und/oder die Anwendungen zwischen Cloud-Plattformen migriert.
11 zeigt eine Halbleiterbaugruppenvorrichtung 192. Die dargestellte Vorrichtung 192 weist ein oder mehrere Substrate 194 (beispielsweise Silicium, Saphir, Galliumarsenid) und Logik 196 (beispielsweise Transistor-Array und andere Integrierte-Schaltung/IC-Komponenten), die mit dem einen oder den mehreren Substraten 194 gekoppelt ist, auf. Die Logik 196 kann zumindest teilweise in Konfigurierbare-Logik- oder Festfunktionalitäts-Logikhardware implementiert sein. Bei einem Beispiel implementiert die Logik 196 einen oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B), wie bereits erörtert. Demgemäß kann die Logik 196 einen Cloud-Dienstaufruf in einer Anwendung erkennen, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, und eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform auswählen. Die Logik 196 kann auch einen für die erste Plattform spezifischen Dienstaufruf automatisch auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes erzeugen.
Überdies kann die Logik 196 eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform auswählen und automatisch einen für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes erzeugen. Die dargestellte Vorrichtung 192 weist daher zumindest in dem Maße eine erhöhte Leistungsfähigkeit auf, dass sie Anwendungen mit generischen Cloud-Dienstaufrufen auf Cloud-Plattformen portiert und/oder die Anwendungen zwischen Cloud-Plattformen migriert.
Bei einem Beispiel weist die Logik 196 Transistorkanalgebiete auf, die innerhalb des einen oder der mehreren Substrate 194 angeordnet (beispielsweise darin eingebettet) sind. Demgemäß kann die Schnittstelle zwischen der Logik 196 und dem einen oder den mehreren Substraten 194 kein abrupter Übergang sein. Die Logik 196 kann auch als eine Epitaxieschicht, die auf einem anfänglichen Wafer des einen oder der mehreren Substrate 194 aufgewachsen ist, aufweisend angesehen werden.
12 zeigt einen Prozessorkern 200 gemäß einer Ausführungsform. Der Prozessorkern 200 kann der Kern für einen beliebigen Prozessortyp in der Art eines Mikroprozessors, eines eingebetteten Prozessors, eines digitalen Signalprozessors (DSP), eines Netzprozessors oder einer anderen Vorrichtung zur Ausführung von Code sein. Wenngleich in 12 nur ein Prozessorkern 200 dargestellt ist, kann ein Verarbeitungselement alternativ mehr als einen von dem in 12 dargestellten Prozessorkern 200 aufweisen. Der Prozessorkern 200 kann ein Einzel-Thread-Kern sein, oder er kann für zumindest eine Ausführungsform in der Hinsicht mehrere Threads aufweisen, dass er mehr als einen Hardware-Thread-Kontext (oder „logischen Prozessor“) pro Kern aufweisen kann.
12 zeigt auch einen Speicher 270, der mit dem Prozessorkern 200 gekoppelt ist. Der Speicher 270 kann einer von einer breiten Vielfalt von Speichern (einschließlich verschiedener Schichten einer Speicherhierarchie) sein, die Fachleuten bekannt sind oder auf andere Weise zur Verfügung stehen. Der Speicher 270 kann einen oder mehrere Codebefehle 213 aufweisen, die durch den Prozessorkern 200 auszuführen sind, wobei der Code 213 einen oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B), wie bereits erörtert, implementieren kann. Der Prozessorkern 200 folgt einer durch den Code 213 angegebenen Programmsequenz von Befehlen. Jeder Befehl kann in einen Vorverarbeitungsabschnitt 210 eingegeben werden und durch einen oder mehrere Decoder 220 verarbeitet werden. Der Decoder 220 kann als Ausgabe eine Mikrooperation in der Art einer Mikrooperation fester Breite in einem vordefinierten Format erzeugen oder andere Befehle, Mikrobefehle oder Steuersignale erzeugen, welche den ursprünglichen Codebefehl widerspiegeln. Der dargestellte Vorverarbeitungsabschnitt 210 weist auch eine Registerumbenennungslogik 225 und eine Planungslogik 230 auf, die im Allgemeinen Ressourcen zuordnen und den Betrieb entsprechend dem umgewandelten Befehl für die Ausführung einreihen.
Der Prozessorkern 200 weist wie dargestellt eine Ausführungslogik 250 mit einem Satz von Ausführungseinheiten 255-1 bis 255-N auf. Einige Ausführungsformen können eine Anzahl von Ausführungseinheiten aufweisen, die spezifischen Funktionen oder Funktionssätzen zugewiesen sind. Andere Ausführungsformen können nur eine Ausführungseinheit oder eine Ausführungseinheit, die eine bestimmte Funktion ausführen kann, aufweisen. Die dargestellte Ausführungslogik 250 führt die durch Codebefehle spezifizierten Operationen aus.
Nach Abschluss der Ausführung der durch die Codebefehle spezifizierten Operationen zieht eine nachgeschaltete Logik 260 die Befehle des Codes 213 zurück. Gemäß einer Ausführungsform ermöglicht der Prozessorkern 200 eine Ausführung außerhalb der Reihenfolge, erfordert jedoch ein Zurückziehen von Befehlen in der Reihenfolge. Die Zurückziehungslogik 265 kann eine Vielzahl Fachleuten bekannter Formen annehmen (beispielsweise Umordnungspuffer oder dergleichen). Auf diese Weise wird der Prozessorkern 200 während der Ausführung des Codes 213 zumindest in Bezug auf die vom Decoder erzeugte Ausgabe, die Hardwareregister und -tabellen, die von der Registerumbenennungslogik 225 verwendet werden, und jegliche Register (nicht dargestellt), die von der Ausführungslogik 250 modifiziert werden, transformiert.
Wenngleich dies in 12 nicht dargestellt ist, kann ein Verarbeitungselement andere Elemente auf dem Chip mit dem Prozessorkern 200 aufweisen. Beispielsweise kann ein Verarbeitungselement eine Speichersteuerlogik zusammen mit dem Prozessorkern 200 aufweisen. Das Verarbeitungselement kann eine E/A-Steuerlogik und/oder eine mit Speichersteuerlogik integrierte E/A-Steuerlogik aufweisen. Das Verarbeitungselement kann auch einen oder mehrere Caches aufweisen.
13 zeigt ein Blockdiagramm eines Rechensystems 1000 gemäß einer Ausführungsform. 13 zeigt ein Mehrprozessorsystem 1000, das ein erstes Verarbeitungselement 1070 und ein zweites Verarbeitungselement 1080 aufweist. Wenngleich zwei Verarbeitungselemente 1070 und 1080 dargestellt sind, ist zu verstehen, dass eine Ausführungsform des Systems 1000 auch ein solches Verarbeitungselement aufweisen kann.
Das System 1000 ist als ein Punkt-zu-Punkt-Zwischenverbindungssystem dargestellt, wobei das erste Verarbeitungselement 1070 und das zweite Verarbeitungselement 1080 über eine Punkt-zu-Punkt-Zwischenverbindung 1050 gekoppelt sind. Es sei bemerkt, dass einige oder alle der in 13 dargestellten Zwischenverbindungen an Stelle einer Punkt-zu-Punkt-Zwischenverbindung als ein Multi-Drop-Bus implementiert werden können.
Wie in 13 dargestellt ist, kann jedes der Verarbeitungselemente 1070 und 1080 ein Mehrkernprozessor sein, der erste und zweite Prozessorkerne aufweist (d. h. Prozessorkerne 1074a und 1074b und Prozessorkerne 1084a und 1084b). Diese Kerne 1074a, 1074b, 1084a, 1084b können dafür ausgelegt sein, einen Befehlscode ähnlich wie vorstehend in Zusammenhang mit 12 erörtert auszuführen.
Jedes Verarbeitungselement 1070, 1080 kann wenigstens einen geteilten Cache 1896a, 1896b aufweisen. Der geteilte Cache 1896a, 1896b kann Daten (beispielsweise Befehle) speichern, die von einer oder mehreren Komponenten des Prozessors in der Art der Kerne 1074a, 1074b bzw. 1084a, 1084b verwendet werden. Beispielsweise kann der geteilte Cache 1896a, 1896b in einem Speicher 1032, 1034 gespeicherte Daten für einen schnelleren Zugriff durch Komponenten des Prozessors lokal cachen. Gemäß einer oder mehreren Ausführungsformen kann der geteilte Cache 1896a, 1896b einen oder mehrere Mid-Level-Caches in der Art eines Level-2(L2)-, Level-3(L3)-, Level-4(L4)- oder anderen Cache-Levels, einen Last-Level-Cache (LLC) und/oder Kombinationen davon aufweisen.
Wenngleich sie nur mit zwei Verarbeitungselementen 1070, 1080 dargestellt sind, ist zu verstehen, dass der Geltungsbereich der Ausführungsformen nicht darauf beschränkt ist. Gemäß anderen Ausführungsformen können ein oder mehrere zusätzliche Verarbeitungselemente in einem gegebenen Prozessor vorhanden sein. Alternativ können ein oder mehrere Verarbeitungselemente 1070, 1080 ein anderes Element als ein Prozessor sein, wie ein Beschleuniger oder ein feldprogrammierbares Gate-Array. Beispielsweise kann das eine oder können die mehreren zusätzlichen Verarbeitungselemente einen oder mehrere zusätzliche Prozessoren, die dem ersten Prozessor 1070 gleichen, einen oder mehrere zusätzliche Prozessoren, die zum ersten Prozessor 1070 heterogen oder asymmetrisch sind, Beschleuniger (beispielsweise in der Art von Grafikbeschleunigern oder digitalen Signalverarbeitungseinheiten (DSP-Einheiten)), feldprogrammierbare Gate-Arrays oder ein anderes Verarbeitungselement aufweisen. Es kann eine Vielzahl von Unterschieden zwischen den Verarbeitungselementen 1070, 1080 in Bezug auf ein Spektrum von Gütemetriken, einschließlich architektonischer, mikroarchitektonischer, thermischer, Stromverbrauchseigenschaften usw., geben. Diese Unterschiede können sich effektiv als Asymmetrie und Heterogenität zwischen den Verarbeitungselementen 1070, 1080 manifestieren. Für zumindest eine Ausführungsform können sich die verschiedenen Verarbeitungselemente 1070, 1080 im selben Die-Gehäuse befinden.
Das erste Verarbeitungselement 1070 kann ferner eine Speichersteuereinrichtungslogik (MC) 1072 und Punkt-zu-Punkt-(P-P)-Schnittstellen 1076 und 1078 aufweisen. Ähnlich kann das zweite Verarbeitungselement 1080 eine MC 1082 und P-P-Schnittstellen 1086 und 1088 aufweisen. Wie in 13 dargestellt ist, koppeln die MCs 1072 und 1082 die Prozessoren mit jeweiligen Speichern, nämlich einem Speicher 1032 und einem Speicher 1034, die Teile eines lokal an den jeweiligen Prozessoren angebrachten Hauptspeichers sein können. Wenngleich die MCs 1072 und 1082 als in die Verarbeitungselemente 1070, 1080 integriert dargestellt sind, kann die MC-Logik für alternative Ausführungsformen eine diskrete Logik außerhalb der Verarbeitungselemente 1070, 1080 statt darin integriert sein.
Das erste Verarbeitungselement 1070 und das zweite Verarbeitungselement 1080 können über jeweilige P-P-Zwischenverbindungen 1076, 1086 mit einem E/A-Untersystem 1090 gekoppelt sein. Wie in 13 dargestellt ist, weist das E/A-Untersystem 1090 P-P-Schnittstellen 1094 und 1098 auf. Ferner weist das E/A-Untersystem 1090 eine Schnittstelle 1092 zum Koppeln des E/A-Untersystems 1090 mit einer Hochleistungs-Grafikmaschine 1038 auf. Gemäß einer Ausführungsform kann der Bus 1049 verwendet werden, um die Grafikmaschine 1038 mit dem E/A-Untersystem 1090 zu koppeln. Alternativ kann eine Punkt-zu-Punkt-Zwischenverbindung diese Komponenten koppeln.
Das E/A-Untersystem 1090 kann wiederum über eine Schnittstelle 1096 mit einem ersten Bus 1016 gekoppelt sein. Gemäß einer Ausführungsform kann der erste Bus 1016 ein Peripheriekomponenten-Zwischenverbindungs(PCI)-Bus oder ein Bus in der Art eines PCI-Express-Busses oder eines anderen E/A-Zwischenverbindungsbusses der dritten Generation sein, wenngleich der Geltungsbereich der Ausführungsformen nicht darauf beschränkt ist.
Wie in 13 dargestellt ist, können verschiedene E/A-Vorrichtungen 1014 (beispielsweise biometrische Scanner, Lautsprecher, Kameras, Sensoren) zusammen mit einer Busbrücke 1018, die den ersten Bus 1016 mit einem zweiten Bus 1020 koppeln kann, mit dem ersten Bus 1016 gekoppelt sein. Gemäß einer Ausführungsform kann der zweite Bus 1020 ein Bus mit einer geringen Stiftanzahl (LPC-Bus) sein. Verschiedene Vorrichtungen können mit dem zweiten Bus 1020 gekoppelt werden, einschließlich beispielsweise einer Tastatur/einer Maus 1012, einer oder mehrerer Kommunikationsvorrichtungen 1026 und einer Datenspeichereinheit 1019 in der Art eines Plattenlaufwerks oder einer anderen Massenspeichervorrichtung, die gemäß einer Ausführungsform einen Code 1030 aufweisen kann. Der dargestellte Code 1030 kann ein oder mehrere Aspekte des Verfahrens 60 (4), des Verfahrens 70 (5), des Verfahrens 100 (7), des Verfahrens 120 (8), des Verfahrens 130 (9A) und/oder des Verfahrens 140 (9B) aufweisen, wie bereits erörtert. Ferner kann eine Audio-E/A 1024 mit dem zweiten Bus 1020 gekoppelt sein und kann eine Batterie 1010 dem Rechensystem 1000 Strom zuführen.
Es sei bemerkt, dass auch andere Ausführungsformen erwogen werden. Beispielsweise kann an Stelle der Punkt-zu-Punkt-Architektur aus 13 ein System einen Multi-Drop-Bus oder eine andere derartige Kommunikationstopologie implementieren. Auch können die Elemente aus 13 alternativ unter Verwendung von mehr oder weniger integrierten Chips als in 13 dargestellt partitioniert werden.
Zusätzliche Bemerkungen und Beispiele:
Beispiel 1 weist ein Rechensystem mit erhöhter Leistungsfähigkeit auf, das eine Netzsteuereinrichtung, einen Prozessor, der mit der Netzsteuereinrichtung gekoppelt ist, und einen Speicher, der mit dem Prozessor gekoppelt ist, umfasst, wobei der Speicher einen Satz ausführbarer Programmbefehle umfasst, die, wenn sie durch den Prozessor ausgeführt werden, das Rechensystem veranlassen, einen Cloud-Dienstaufruf in einer Anwendung zu erkennen, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, eine erste Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform auszuwählen und automatisch einen für die erste Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes zu erzeugen.
Beispiel 2 weist das Rechensystem nach Beispiel 1 auf, wobei die Befehle, wenn sie ausgeführt werden, das Rechensystem veranlassen, den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuzuordnen.
Beispiel 3 weist das Rechensystem nach einem der Beispiele 1 bis 2 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine zweite Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform auszuwählen, automatisch einen für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes zu erzeugen und den Cloud-Dienstaufruf dem für die zweite Plattform spezifischen Dienstaufruf zuzuordnen.
Beispiel 4 weist das Rechensystem nach Beispiel 3 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform auszuführen.
Beispiel 5 weist das Rechensystem nach Beispiel 4 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, die Übertragung über eine Bitmap zu verfolgen.
Beispiel 6 weist das Rechensystem nach Beispiel 4 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Laufzeitinstanz des Cloud-Dienstaufrufs zu erkennen und ansprechend auf die Laufzeitinstanz den für die erste Plattform spezifischen Dienstaufruf und/oder den für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage eines Status der Übertragung selektiv auszugeben.
Beispiel 7 weist eine Halbleitervorrichtung auf, die ein oder mehrere Substrate und mit dem einen oder den mehreren Substraten gekoppelte Logik umfasst, wobei die Logik zumindest teilweise in einer oder mehreren von einer konfigurierbaren Logik oder einer Festfunktionalitäts-Hardwarelogik implementiert ist, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
Beispiel 8 weist die Halbleitervorrichtung nach Beispiel 7 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuordnen soll.
Beispiel 9 weist die Halbleitervorrichtung nach einem der Beispiele 7 bis 8 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
Beispiel 10 weist die Halbleitervorrichtung nach Beispiel 9 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform ausführen soll.
Beispiel 11 weist die Halbleitervorrichtung nach Beispiel 10 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik die Übertragung über eine Bitmap verfolgen soll.
Beispiel 12 weist die Halbleitervorrichtung nach Beispiel 10 auf, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
Beispiel 13 weist wenigstens ein computerlesbares Speichermedium auf, das einen Satz ausführbarer Programmbefehle umfasst, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen, Folgendes auszuführen: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
Beispiel 14 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 13 auf, wobei die Befehle, wenn sie ausgeführt werden, das Rechensystem veranlassen, den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuzuordnen.
Beispiel 15 weist das wenigstens eine computerlesbare Speichermedium nach einem der Beispiele 13 bis 14 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, Folgendes auszuführen: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
Beispiel 16 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 15 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform auszuführen.
Beispiel 17 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 16 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, die Übertragung über eine Bitmap zu verfolgen.
Beispiel 18 weist das wenigstens eine computerlesbare Speichermedium nach Beispiel 16 auf, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Laufzeitinstanz des Cloud-Dienstaufrufs zu erkennen und ansprechend auf die Laufzeitinstanz den für die erste Plattform spezifischen Dienstaufruf und/oder den für die zweite Plattform spezifischen Dienstaufruf auf der Grundlage eines Status der Übertragung selektiv auszugeben.
Beispiel 19 weist ein Verfahren zum Betreiben eines Rechensystems mit erhöhter Leistungsfähigkeit auf, wobei das Verfahren Folgendes umfasst: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
Beispiel 20 weist das Verfahren nach Beispiel 19 auf, wobei der Cloud-Dienstaufruf ferner dem für die erste Plattform spezifischen Dienstaufruf zugeordnet wird.
Beispiel 21 weist das Verfahren nach einem der Beispiele 19 bis 20 auf, und es weist ferner Folgendes auf Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.
Beispiel 22 weist das Verfahren nach Beispiel 21 auf, wobei ferner eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform ausgeführt wird.
Beispiel 23 weist das Verfahren nach Beispiel 22 auf, wobei ferner die Übertragung über eine Bitmap verfolgt wird.
Beispiel 24 weist das Verfahren nach Beispiel 22 auf, und es weist ferner Folgendes auf: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
Beispiel 25 weist Mittel zur Ausführung des Verfahrens nach einem der Beispiele 19 bis 24 auf.
Demgemäß stellt die hier beschriebene Technologie eine vereinheitlichte Programmierschnittstelle bereit, die auf generische Cloud-Dienste und eine Laufzeit, die eine Anwendung oder Teile von ihr transparent bewegt, um von verschiedenen Cloud-Verkäuferdiensten zu profitieren, abzielt. Die Cloud-Anwendungsentwickler können ihren Code einmal unter Verwendung generischer Cloud-Dienst-APIs schreiben, wie hier beschrieben. Eine Laufzeit kann die generische API auf verfügbare/optimale Cloud-Dienste portieren/abbilden (beispielsweise durch Wählen aus einem Pool von Verkäufern). Die Laufzeit kann auch eine allmähliche Migration der Anwendung oder spezifischer Module von einem Cloud-Verkäufer zu einem anderen bereitstellen, ohne den Dienst zu unterbrechen.
Ausführungsformen sind für eine Verwendung mit allen Typen von Chips integrierter Halbleiterschaltungen („IC-Chips“) geeignet. Beispiele dieser IC-Chips umfassen Prozessoren, Steuereinrichtungen, Chipsatz-Komponenten, programmierbare Logik-Arrays (PLA), Speicherchips, Netzchips, Systems-on-Chip (SoC), SSD/NAND-Steuereinrichtungs-ASICs und dergleichen, sind jedoch nicht darauf beschränkt. Zusätzlich sind in einigen der Zeichnungen Signalleitungen durch Linien dargestellt. Einige können verschieden sein, um weitere Signalteilwege anzugeben, eine Nummernbezeichnung aufweisen, um eine Nummer von Signalteilwegen anzugeben, und/oder an einem oder mehreren Enden Pfeile aufweisen, um die primäre Informationsflussrichtung anzugeben. Dies sollte jedoch nicht einschränkend ausgelegt werden. Vielmehr können solche zusätzlichen Einzelheiten zusammen mit einer oder mehreren beispielhaften Ausführungsformen verwendet werden, um das Verständnis einer Schaltung zu erleichtern. Jegliche dargestellte Signalleitungen, ob sie zusätzliche Informationen aufweisen oder nicht, können tatsächlich ein oder mehrere Signale umfassen, die sich in mehreren Richtungen ausbreiten, und durch einen geeigneten Typ eines Signalschemas implementiert werden, beispielsweise als digitale oder analoge Leitungen, die mit differenziellen Paaren, optischen Faserleitungen und/oder unsymmetrischen Leitungen implementiert sind.
Beispielhafte Größen/Modelle/Werte/Bereiche können angegeben worden sein, wenngleich Ausführungsformen nicht darauf beschränkt sind. Weil die Herstellungstechniken (beispielsweise die Photolithographie) im Laufe der Zeit reifen, wird erwartet, dass Vorrichtungen mit einer geringeren Größe hergestellt werden könnten. Zusätzlich können innerhalb der Figuren zur einfachen Darstellung und Erörterung und um bestimmte Aspekte der Ausführungsformen nicht unklar zu machen, wohlbekannte Strom/Masse-Verbindungen zu IC-Chips und anderen Komponenten dargestellt sein, oder dies kann nicht der Fall sein. Ferner können Anordnungen in Blockdiagrammform dargestellt sein, um es zu verhindern, Ausführungsformen unklar zu machen, und auch angesichts der Tatsache, dass spezifische Einzelheiten in Bezug auf die Implementation solcher Blockdiagrammanordnungen in hohem Maße vom Rechensystem abhängen, innerhalb dessen die Ausführungsform zu implementieren ist, d. h. diese spezifischen Einzelheiten sollten für Fachleute leicht verständlich sein. Wo spezifische Details (beispielsweise Schaltungen) dargelegt sind, um beispielhafte Ausführungsformen zu beschreiben, sollte Fachleuten verständlich sein, dass Ausführungsformen ohne eine Variation dieser spezifischen Details oder mit einer Variation von diesen verwirklicht werden können. Die Beschreibung ist demgemäß als erläuternd und nicht als einschränkend anzusehen.
Der Begriff „gekoppelt“ kann hier verwendet werden, um auf einen Typ einer Beziehung, ob direkt oder indirekt, zwischen den fraglichen Komponenten Bezug zu nehmen und für elektrische, mechanische, Fluid-, optische, elektromagnetische, elektromechanische oder andere Verbindungen gelten. Zusätzlich können die Begriffe „erster“, „zweiter“ usw. hier nur verwendet werden, um die Erörterung zu erleichtern, und sie weisen keine bestimmte zeitliche oder chronologische Bedeutung auf, es sei denn, dass etwas anderes angegeben wird.
Wie in dieser Anmeldung und in den Ansprüchen verwendet, kann eine Liste durch den Begriff „einer oder mehrere von“ verbundener Bestandteile eine beliebige Kombination der aufgelisteten Bestandteile bedeuten. Beispielsweise können die Ausdrücke „eine oder mehrere von A, B oder C“ A; B; C; A und B; A und C; B und C; oder A, B und C bedeuten.
Fachleute werden anhand der vorstehenden Beschreibung verstehen, dass die breiten Techniken der Ausführungsformen in einer Vielzahl von Formen implementiert werden können. Daher sollte, wenngleich die Ausführungsformen in Zusammenhang mit bestimmten Beispielen davon beschrieben wurden, der wahre Geltungsbereich der Ausführungsformen nicht darauf begrenzt sein, weil andere Modifikationen sachkundigen Anwendern bei der Betrachtung der Zeichnungen, der Beschreibung und der folgenden Ansprüche verständlich werden.

Claims

Halbleitervorrichtung, welche Folgendes umfasst: ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, wobei die Logik zumindest teilweise in einer oder mehreren von einer konfigurierbaren Logik oder einer Festfunktionalitäts-Hardwarelogik implementiert ist, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
Halbleitervorrichtung nach Anspruch 1, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuordnen soll.
Halbleitervorrichtung nach einem der Ansprüche 1 bis 2, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf
Halbleitervorrichtung nach Anspruch 3, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform ausführen soll.
Halbleitervorrichtung nach Anspruch 4, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik die Übertragung über eine Bitmap verfolgen soll.
Halbleitervorrichtung nach Anspruch 4, wobei die mit dem einen oder den mehreren Substraten gekoppelte Logik Folgendes ausführen soll: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
Computerlesbares Speichermedium bzw. computerlesbare Speichermedien, umfassend einen Satz ausführbarer Programmbefehle, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen, Folgendes auszuführen: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sein sollen, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 7, wobei die Befehle, wenn sie ausgeführt werden, das Rechensystem veranlassen, den Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zuzuordnen.
Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach einem der Ansprüche 7 bis 8, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, Folgendes auszuführen: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf
Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 9, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, eine Übertragung von Zustandsdaten von der ersten Cloud-Plattform zur zweiten Cloud-Plattform auszuführen.
Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 10, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, die Übertragung über eine Bitmap zu verfolgen.
Computerlesbares Speichermedium bzw. computerlesbare Speichermedien nach Anspruch 10, wobei die Befehle, wenn sie ausgeführt werden, ferner das Rechensystem veranlassen, Folgendes auszuführen: Erkennen einer Laufzeitinstanz des Cloud-Dienstaufrufs und selektives Ausgeben des für die erste Plattform spezifischen Dienstaufrufs und/oder des für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage eines Status der Übertragung ansprechend auf die Laufzeitinstanz.
Verfahren, welches Folgendes umfasst: Erkennen eines Cloud-Dienstaufrufs in einer Anwendung, wobei plattformspezifische Parameter im Cloud-Dienstaufruf unspezifiziert sind, Auswählen einer ersten Cloud-Plattform auf der Grundlage einer oder mehrerer Leistungsfähigkeitsrandbedingungen in Zusammenhang mit dem Cloud-Dienstaufruf und eines ersten Parametersatzes in Zusammenhang mit der ersten Cloud-Plattform und automatisches Erzeugen eines für die erste Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des ersten Parametersatzes.
Verfahren nach Anspruch 13, wobei ferner der Cloud-Dienstaufruf dem für die erste Plattform spezifischen Dienstaufruf zugeordnet wird.
Verfahren nach einem der Ansprüche 13 bis 14, welches ferner Folgendes aufweist: Auswählen einer zweiten Cloud-Plattform auf der Grundlage der einen oder der mehreren Leistungsfähigkeitsrandbedingungen und eines zweiten Parametersatzes in Zusammenhang mit der zweiten Cloud-Plattform, automatisches Erzeugen eines für die zweite Plattform spezifischen Dienstaufrufs auf der Grundlage des Cloud-Dienstaufrufs und des zweiten Parametersatzes und Zuordnen des Cloud-Dienstaufrufs zum für die zweite Plattform spezifischen Dienstaufruf.