DE112021003803T5

DE112021003803T5 - Pool-verwaltung für den anwendungsstart in einer bordeinheit

Info

Publication number: DE112021003803T5
Application number: DE112021003803.6T
Authority: DE
Inventors: Masakuni Okada; Hayato Uenohara; Takuya Matsunaga
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2020-07-16
Filing date: 2021-07-13
Publication date: 2023-05-17
Also published as: WO2022013735A1; US11915024B2; GB2611989A; AU2021308570A1; US20220019453A1; JP2023535316A; CN116249962A; AU2021308570B2; KR20230027144A

Abstract

ES wird ein Verfahren, ein Computerprogrammprodukt und ein System für ein Vorab-Pooling von Komponenten aus virtuellen Maschinen (VMs) vor dem Anwendungsstart vorgestellt. Das Verfahren weist ein Lesen eines VM-Pool-Manifests durch einen VM-Pool-Verwalter auf. Das VM-Pool-Manifest weist eine anfängliche Anzahl von virtuellen Maschinen auf, die gestartet werden sollen, wie vielen virtuellen Maschinen Ressourcen zugeordnet werden sollen, sowie eine Menge von zuzuordnenden Ressourcen auf Grundlage einer VM-Ressourcendefinition. Das Verfahren enthält außerdem ein Starten einer Mehrzahl von Basis-VMs in einem VM-Pool auf Grundlage der anfänglichen Anzahl, die durch das VM-Pool-Manifest bereitgestellt wird. Die Basis-VMs verfügen über keine anfänglichen Anwendungszuweisungen. Das Verfahren enthält des Weiteren ein Zuordnen anfänglicher Ressourcen zu einem Teil der Basis-VMs auf Grundlage einer VM-Ressourcendefinition in dem VM-Pool-Manifest. Das Verfahren enthält ein Laden von Kernprogrammpaketen in den Teil der Basis-VMs.

Description

HINTERGRUND
Die vorliegende Offenbarung bezieht sich auf die Anwendungsstartgeschwindigkeit in einer Bordeinheit und im Besonderen auf ein Verbessern der Anwendungsstartgeschwindigkeit durch Aufteilen des Anwendungsstartprozesses unter Verwendung effizienter Pool-Verwaltungsmethoden.
Technologie für das Internet der Dinge (Information of Things, loT) ermöglicht eine Funktionserweiterbarkeit, indem die Fähigkeit bereitgestellt wird, zusätzliche Anwendungen zu einer Bordeinheit (z.B. einem Navigationssystem) hinzuzufügen. Ergänzend dazu findet eine Ausweitung der Entwicklung von Anwendungen in Fahrzeugen statt, um Anwendungen die Steuerung von Systemfunktionen (z.B. Cockpit-Kamera, Klimaanlage, Fahrzeuginformationsverwaltung) innerhalb eines Fahrzeugs zu ermöglichen. Diese Anwendungen werden als ein integraler Teil der Kernfunktionalität einer Bordeinheit entwickelt, was Systemfunktionen ermöglicht, die als austauschbare Anwendungen innerhalb der Bordeinheit installiert werden können.
KURZDARSTELLUNG
Verschiedene Ausführungsformen der vorliegenden Offenbarung sind auf ein computerrealisiertes Verfahren eines Vorab-Poolings von Komponenten aus virtuellen Maschinen (VM) vor dem Anwendungsstart gerichtet. Das computerrealisierte Verfahren enthält ein Lesen eines VM-Pool-Manifests durch einen VM-Pool-Verwalter. Das VM-Pool-Manifest enthält eine anfängliche Anzahl von virtuellen Maschinen, die gestartet werden sollen. Das VM-Pool-Manifest kann auch enthalten, wie vielen virtuellen Maschinen Ressourcen zugeordnet werden sollen, die Anzahl von zuzuordnenden Ressourcen auf Grundlage einer VM-Ressourcendefinition, die Anzahl von virtuellen Maschinen ohne eine Ressourcenzuordnung, eine Standardumgebung sowie einen Parameter, der eine maximale Anzahl an ausführbaren Anwendungen zu einem bestimmten Zeitpunkt angibt. Das computerrealisierte Verfahren enthält außerdem ein Starten einer Mehrzahl von Basis-VMs in einem VM-Pool auf Grundlage der anfänglichen Anzahl, die durch das VM-Pool-Manifest bereitgestellt wird. Die Basis-VMs verfügen über keine anfänglichen Anwendungszuweisungen. Das computerrealisierte Verfahren enthält des Weiteren ein Zuordnen anfänglicher Ressourcen zu einem Teil der Basis-VMs auf Grundlage einer VM-Ressourcendefinition in dem VM-Pool-Manifest. Das computerrealisierte Verfahren enthält ein Laden von Kernprogrammpaketen in den Teil der Basis-VMs.
Zusätzliche Ausführungsformen der vorliegenden Offenbarung enthalten ein Computerprogrammprodukt für ein Vorab-Pooling von VM-Komponenten vor dem Anwendungsstart, das ein computerlesbares Speichermedium mit darin enthaltenen Programmanweisungen enthalten kann, wobei die Programmanweisungen durch einen Prozessor ausführbar sind, um ein Verfahren durchzuführen. Das Verfahren enthält ein Lesen eines VM-Pool-Manifests durch einen VM-Pool-Verwalter. Das VM-Pool-Manifest enthält eine anfängliche Anzahl von virtuellen Maschinen, die gestartet werden sollen. Das VM-Pool-Manifest kann auch enthalten, wie vielen virtuellen Maschinen Ressourcen zugeordnet werden sollen, die Anzahl von zuzuordnenden Ressourcen auf Grundlage einer VM-Ressourcendefinition, die Anzahl von virtuellen Maschinen ohne eine Ressourcenzuordnung, eine Standardumgebung sowie einen Parameter, der eine maximale Anzahl an ausführbaren Anwendungen zu einem bestimmten Zeitpunkt angibt. Das Verfahren enthält außerdem ein Starten einer Mehrzahl von Basis-VMs in einem VM-Pool auf Grundlage der anfänglichen Anzahl, die durch das VM-Pool-Manifest bereitgestellt wird. Die Basis-VMs verfügen über keine anfänglichen Anwendungszuweisungen. Das Verfahren enthält des Weiteren ein Zuordnen anfänglicher Ressourcen zu einem Teil der Basis-VMs auf Grundlage einer VM-Ressourcendefinition in dem VM-Pool-Manifest. Das Verfahren enthält ein Laden von Kernprogrammpaketen in den Teil der Basis-VMs.
Weitere Ausführungsformen sind auf ein VM-Pool-Verwaltungssystem für ein Vorab-Pooling von VM-Komponenten vor dem Anwendungsstart gerichtet und werden konfiguriert, um die oben beschriebenen Verfahren durchzuführen. Die vorliegende Zusammenfassung soll nicht jeden Aspekt einer jeden Realisierung und/oder einer jeden Ausführungsform der vorliegenden Offenbarung veranschaulichen.
Figurenliste
Diese und andere Merkmale, Aspekte und Vorteile der vorliegenden Offenbarung werden aus der folgenden Beschreibung, den beigefügten Ansprüchen und zugehörigen Zeichnungen deutlich, wobei:

1 ein Blockschaubild ist, das eine Bordeinheit in einem Fahrzeug gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
2 ein Blockschaubild ist, das ein VM-Pool-Verwaltungssystem gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht;
3 ein Ablaufplan für ein Vorab-Pooling von VM-Komponenten vor dem Anwendungsstart gemäß Ausführungsformen der vorliegenden Offenbarung ist;
4 ein allgemeines Blockschaubild ist, das ein Beispiel-Computersystem veranschaulicht, das gemäß Ausführungsformen der vorliegenden Offenbarung zum Realisieren eines oder mehrerer der hierin beschriebenen Verfahren, Werkzeuge und Module sowie etwaiger verwandter Funktionen verwendet werden kann;
5 eine Cloud-Computing-Umgebung gemäß Ausführungsformen der vorliegenden Offenbarung darstellt;
6 Abstraktionsmodellschichten gemäß Ausführungsformen der vorliegenden Offenbarung darstellt.

Obwohl die vorliegende Offenbarung für verschiedene Modifikationen und alternative Formen offen ist, wurden Besonderheiten hiervon in den Zeichnungen beispielhaft gezeigt und werden im Detail beschrieben. Dabei sollte jedoch klar sein, dass keine Beschränkung auf die bestimmten, beschriebenen Ausführungsformen vorgesehen ist. Vielmehr sollen alle Modifikationen, Entsprechungen und Alternativen abgedeckt sein, die unter den inhaltlichen Umfang der vorliegenden Offenbarung fallen. Gleichlautende Bezugsziffern sollen gleichartige Teile in den beigefügten Zeichnungen bezeichnen.
AUSFÜHRLICHE BESCHREIBUNG
Die vorliegende Offenbarung bezieht sich auf die Anwendungsstartgeschwindigkeit in einer Bordeinheit und im Besonderen auf ein Verbessern der Anwendungsstartgeschwindigkeit durch Aufteilen des Anwendungsstartprozesses unter Verwendung effizienter Pool-Verwaltungsmethoden. Obwohl die vorliegende Offenbarung nicht notwendigerweise auf solche Anwendungen beschränkt ist, lassen sich verschiedene Aspekte der Offenbarung besser würdigen, wenn die verschiedenen Beispiele in diesem Kontext erörtert werden.
Technologie für das Internet der Dinge (Information of Things, loT) ermöglicht eine Funktionserweiterbarkeit, indem die Fähigkeit bereitgestellt wird, zusätzliche Anwendungen zu einer Bordeinheit eines Fahrzeugs (z.B. einem Navigationssystem) hinzuzufügen. Ergänzend dazu findet eine Ausweitung der Entwicklung von Anwendungen in Fahrzeugen statt, um Anwendungen die Steuerung von Systemfunktionen (z.B. Cockpit-Kamera, Klimaanlage, Fahrzeuginformationsverwaltung) innerhalb eines Fahrzeugs zu ermöglichen. Diese Anwendungen werden als ein integraler Teil der Kernfunktionalität einer Bordeinheit entwickelt, die Systemfunktionen ermöglicht, die als austauschbare Anwendungen innerhalb der Bordeinheit installiert werden können.
Eine typische Startprozedur für eine Bordanwendung enthält eine Anwendungsplattform oder ein Kernprogramm zum Betreiben einer Anwendung, die bzw. das zuerst initialisiert wird. Der Initialisierungsprozess enthält ein Lesen einer Anwendung aus einer Speichereinheit, ein Erzeugen eines Prozesses, ein Starten des Kernprogramms der Anwendung und ein Zuordnen von Ressourcen, die für die Anwendung benötigt werden. Die Anwendung wird gestartet, wenn die Steuerung an die Anwendungslogik übertragen wird.
Allerdings bleiben Beschränkungen des Anwendungsstarts bestehen, da Bordeinheiten beschränkte Ressourcen (z.B. Arbeitsspeicher, Speicher, Prozessor) haben. Somit können Bordanwendungen eine Ressourcenobergrenze haben. Gegenwärtige Methoden zum Beschleunigen des Anwendungsstarts enthalten Technologien wie den Ruhezustand. Beim Ruhezustand kann das Betriebssystem vor dem Ausschalten den Betriebszustand einer Anwendung in den Arbeitsspeicher kopieren. Entsprechend kann das Betriebssystem die Anwendung neu starten, indem sie beim Einschalten die Kopie des Betriebszustands wiederherstellt. Allerdings wird das Unterbrechen der Stromversorgung in Fahrzeugen durch einen Befehl zum Ausschalten von Zubehörkomponenten veranlasst, wodurch dem Betriebssystem unter Umständen nicht die Möglichkeit gegeben wird, eine Kopie von Betriebszuständen aller Anwendungen zu erstellen, die möglicherweise ausgeführt werden. Im Gegensatz zu herkömmlichen Datenverarbeitungseinheiten wird des Weiteren nicht zwischen verschiedenen Arten von Ausschaltungen für Bordeinheiten unterschieden. So können Notebook Computer zum Beispiel zwischen Ausschaltbefehlen unterscheiden. Ein Ausschaltbefehl durch Drücken der Einschalttaste kann eine andere Reaktion des Notebooks hervorrufen als ein Ausschaltbefehl durch Schließen des Notebooks. Ein Unterscheiden zwischen verschiedenen Arten von Ausschaltungen kann es dem Betriebssystem solcher Einheiten ermöglichen, Anwendungen, die beim Wechsel einer Einheit in den Schlafzustand ausgeführt werden, in den Ruhezustand zu versetzen, anstatt sie herunterzufahren. Da Bordeinheiten ein Ausschaltereignis des Schlafzustandstyps nicht von einem Ausschaltereignis eines Herunterfahrens unterscheiden können, sind Technologien wie zum Beispiel der Ruhezustand für Bordeinheiten nicht anwendbar.
Andere Methoden wie z.B. eine Hardware-Leistungsverbesserung und Programmausführgeschwindigkeit unter Verwendung einer Vorkompilierung (Ahead-of-Time Compilation, AOT) versuchen ebenfalls, den Anwendungsstart zu beschleunigen. Allerdings können diese Methoden zusätzlichen Mehraufwand verursachen und nur eine begrenzte Verbesserung der Gesamt-Startgeschwindigkeit einer Bordanwendung bereitstellen.
Ausführungsformen der vorliegenden Offenbarung können die obigen und andere Probleme lösen, indem sie ein VM-Pool-Verwaltungssystem verwenden, um vor dem Anwendungsstart ein Vorab-Pooling von VM-Komponenten durchzuführen. Zusätzlich hierzu werden eine Ressourcenzuordnung und Anwendungslogik-Übertragungen für eine Anwendung durchgeführt. Auf diese Weise kann das Anwendungs-Pool-Verwaltungssystem die Startzeit einer Anwendung in einer Bordeinheit beschleunigen. Das VM-Pool-Verwaltungssystem enthält einen VM-Pool-Verwalter, der konfiguriert wird, um virtuelle Maschinen, die von einer Bordeinheit benötigt werden, zu verwalten und zu starten. Der VM-Pool-Verwalter wird außerdem konfiguriert, um anfängliche Ressourcen auf Grundlage eines VM-Pool-Manifests den virtuellen Maschinen zuzuordnen. Das VM-Pool-Verwaltungssystem enthält außerdem einen Anwendungspaket-Verwalter, der konfiguriert wird, um Kernprogrammpakete zu installieren und sie in die virtuellen Maschinen zu laden, die Ressourcen zugeordnet werden. Diese virtuellen Maschinen können innerhalb eines VM-Pools verbleiben und sich so lange in einem Bereitschaftszustand befinden, bis sie durch eine Bordeinheit angefordert werden, um eine Anwendung auszuführen.
Bei manchen Ausführungsformen kann das VM-Pool-Verwaltungssystem zusätzliche virtuelle Maschinen starten, die keine Zuordnung von Ressourcen empfangen. Das VM-Pool-Verwaltungssystem kann diese virtuellen Maschinen so lange in eine Wartekonfiguration versetzen, bis sie benötigt werden. Wenn Ressourcen verfügbar werden, kann der VM-Pool-Verwalter den virtuellen Maschinen in der Wartekonfiguration somit Ressourcen zuordnen und diese virtuellen Maschinen in eine Bereitschaftskonfiguration versetzen.
Bei manchen Ausführungsformen ordnet der VM-Pool-Verwalter den virtuellen Maschinen auf Grundlage eines Ressourcenzuweisungsmusters anfängliche Ressourcen zu. Das Ressourcenzuweisungsmuster kann ein typisches Muster angeben, das eine Bordeinheit während des Betriebs hat. Zum Beispiel kann eine Bordeinheit fünf Anwendungen direkt nach dem Starten sowie weitere sechs Anwendungen nach einer vorgegebenen Zeit ausführen. Das Ressourcenzuweisungsmuster kann den Bedarf der Bordeinheit nachahmen, um dadurch seinen Bedarf vorwegzunehmen.
Ausführungsformen der vorliegenden Offenbarung enthalten einen Anwendungslebenszyklus-Verwalter, der konfiguriert wird, um den Lebenszyklus der Anwendungen zu verwalten, die in einer Bordeinheit ausgeführt werden. Zusätzlich hierzu kann der Anwendungslebenszyklus-Verwalter ermitteln, welchen virtuellen Maschinen Anwendungen zugewiesen werden sollen. Dies kann auf Grundlage der anfänglichen Ressourcen und einer Kernprogrammierung erfolgen, die in die virtuelle Maschine geladen wird. Wenn einer virtuellen Maschine zum Beispiel eine ausreichende Menge an Ressourcen zugeordnet wird, um den Betrieb und die Ausführung einer angeforderten Anwendung zu erlauben, kann der Anwendungslebenszyklus-Verwalter die virtuelle Maschine auswählen und ihr die spezifische Anwendung zuweisen. Andernfalls kann der Anwendungslebenszyklus-Verwalter anfordern, dass der VM-Pool-Verwalter zusätzliche virtuelle Maschinen startet oder geeignete Ressourcen neu zuordnet.
Unter Bezugnahme auf 1 wird ein allgemeines Blockschaubild eines Fahrzeugs 100 mit einer eingebetteten Bordeinheit 105 gezeigt. Das Fahrzeug 100 enthält zusätzlich einen Sensor 160 und eine Kamera 170. Die Bordeinheit 105 enthält eine Steuereinheit 110, eine Speichereinheit 120, eine Datenübertragungseinheit 130, eine Eingabeeinheit 140 und eine Ausgabeeinheit 150. Die Eingabeeinheit 140 wird mit dem Sensor 160 und der Kamera 170 im Datenaustausch gekoppelt.
Die Bordeinheit 105 ist eine Komponente des Fahrzeugs 100 und wird konfiguriert, um Informationen in Zusammenhang mit dem Fahrzeug 100 zu empfangen und zu übertragen. Zusätzlich kann die Bordeinheit 105 Fahrzeugsystemfunktionen wie Fahrmodus, Tempomat, Kameras, Sensoren, Scheinwerfer und dergleichen betreiben. Die Bordeinheit 105 kann außerdem verschiedene Fahrzeugsteuerungen betreiben. Diese Fahrzeugsteuerungen enthalten zum Beispiel Navigationssteuerungen, Heizungs-, Lüftungs- und Klimatisierungssteuerungen (HLK) sowie Steuerungen für die Audio/Video(A/V)-Unterhaltung.
Die Steuereinheit 110 ist eine Komponente der Bordeinheit 105 und wird konfiguriert, um eine oder eine Mehrzahl von Zentraleinheiten (Central Processing Unit, CPU) oder eine Mehrkern-CPU zu verwenden, und enthält einen Festwertspeicher (Read-Only Memory, ROM), einen Direktzugriffsspeicher (Random Access Memory, RAM), eine Eingabe/Ausgabe-Schnittstelle, einen Taktgeber und dergleichen. Die Steuereinheit 110 ist eine Ermittlungseinheit, die einen Betrieb entsprechender, beteiligter Einheiten steuert, indem sie ein Programm ausführt, das in einem eingebetteten ROM gespeichert wird und das unten beschriebene VM-Pool-Verwaltungssystem 200 ausführt.
Die Speichereinheit 120 ist eine Komponente der Bordeinheit, die konfiguriert wird, um Informationen zu dem Fahrzeug 100 und der Bordeinheit 105 zu speichern. Bei manchen Ausführungsformen ist die Speichereinheit 120 ein nicht flüchtiger Arbeitsspeicher (z.B. Flash-Arbeitsspeicher, elektrisch löschbarer programmierbarer ROM (Electrically Erasable Programmable Read-Only Memory, (EEPROM)). Die Speichereinheit 120 kann einen oder mehrere Arbeitsspeicher enthalten. Jeder der Arbeitsspeicher in der Speichereinheit 120 ist zum Beispiel ein Halbleiter-Arbeitsspeicher, ein magnetischer Arbeitsspeicher, ein Solid-State-Arbeitsspeicher oder ein optischer Arbeitsspeicher. Jeder Arbeitsspeicher dient zum Beispiel als die Hauptarbeitsspeicher-Einheit, als eine Hilfsspeicher-Einheit oder ein Cache-Arbeitsspeicher. Die Speichereinheit 120 kann jegliche Informationen speichern, die für den Betrieb der Bordeinheit 105 verwendet werden. Zum Beispiel kann die Speichereinheit 120 Anwendungen speichern, die durch die Bordeinheit 105 ausführbar sind.
Die Datenübertragungseinheit 130 ist eine Komponente der Bordeinheit 105, die konfiguriert wird, um Daten mit einem Server auszutauschen. Die Datenübertragungseinheit 130 hat ein oder mehrere Datenübertragungsmodule. Das Datenübertragungsmodul enthält zum Beispiel ein Modul, das mit Standards für die mobile Datenübertragung kompatibel ist, z.B. 4G (vierte Generation), 5G (fünfte Generation), Bluetooth, WLAN, GSM (Global System for Mobile), CDMA (Code Division Multiple Access, CDMA), LTE (Long-Term Evolution), Infrarot (IR) und dergleichen. Zusätzlich hierzu kann die Datenübertragungseinheit eine Datenübertragungseinheit wie z.B. ein Datenübertragungsmodul (Data Communication Modul, DCM) haben. Die Datenübertragungseinheit 130 verbindet die Bordeinheit 105 mit einem Netzwerk, um mit einem Server Daten auszutauschen. Bei manchen Ausführungsformen enthält die Datenübertragungseinheit 130 ein Datenübertragungsmodul, das ein GPS-Empfangsmodul (Global Positioning System, globales Positionsbestimmungssystem) ist, in dem die Bordeinheit 105 durch die Datenübertragungseinheit 130 GPS-Signale empfängt.
Die Eingabeeinheit 140 ist eine Komponente der Bordeinheit 105, bei der es sich um eine Schnittstelle handelt, die ein Signal von außerhalb der Bordeinheit 105 einspeist. Die Eingabeeinheit 140 kann Informationen von einem Sensor 160 oder einer Kamera 170 empfangen, und die Steuereinheit 110 kann die Informationen von dem Sensor 160 und der Kamera 170 erhalten.
Die Ausgabeeinheit 150 ist eine Komponente der Bordeinheit, die konfiguriert wird, um ein Signal auszugeben, das eine Betriebsfunktionalität angibt, zu der das Fahrzeug 100 in der Lage ist. Bei manchen Ausführungsformen ist die Ausgabeeinheit 150 eine Datenübertragungseinheit 130, die mit einem lokalen Netzwerk (Local Area Network, LAN) verbunden wird, oder kann eine Datenübertragungseinheit 130 in Kombination mit der Eingabeeinheit 140 sein.
Es wird darauf verwiesen, dass 1 die repräsentativen Hauptkomponenten einer beispielhaften Bordeinheit 105 darstellen soll. Allerdings können bei manchen Ausführungsformen einzelne Komponenten eine größere oder geringere Komplexität als in 1 gezeigt haben, andere oder zusätzliche Komponenten als die in 1 gezeigten können vorhanden sein, und die Anzahl, Art und Konfiguration solcher Komponenten kann variieren.
2 ist ein Blockschaubild, das ein VM-Pool-Verwaltungssystem 200 für ein Vorab-Pooling von VM-Komponenten vor dem Anwendungsstart gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Das VM-Pool-Verwaltungssystem 200 enthält einen VM-Pool-Verwalter 210, ein VM-Pool-Manifest 220, einen VM-Pool 230, einen Anwendungslebenszyklus-Verwalter 240, Anwendungen 250-1, 250-2, 250-N (zusammenfassend als „Anwendungen 250“ bezeichnet), wobei N eine variable Ganzzahl ist, die für eine beliebige Anzahl von möglichen Anwendungen 250 steht, sowie einen Anwendungspaket-Verwalter 260. Der VM-Pool enthält eine Basis-VM 233-1, 233-2, 233-N (zusammenfassend als „Basis-VMs 233“ bezeichnet), wobei N eine variable Ganzzahl ist, die für eine beliebige Anzahl von möglichen Basis-VMs 233 stehen kann, sowie Ressourcen 235-1, 235-2, 235-N (zusammenfassend als „Ressourcen 235“ bezeichnet), wobei N eine variable Ganzzahl ist, für eine beliebige Anzahl der möglichen Ressourcen 235 stehen kann. Der Anwendungslebenszyklus-Verwalter 240 enthält einen Anwendungslogik-Injektionsverwalter 244 und einen Anwendungsressourcen-Zuweiser 248. Die Anwendungen 250 enthalten eine Ressourceninformationen 251-1, 251-2, 251-N (zusammenfassend als „Ressourceninformation 251“ bezeichnet), wobei N eine variable Ganzzahl ist, die für eine beliebige Anzahl einer möglichen Ressourceninformation 251 stehen kann.
Der VM-Pool-Verwalter 210 ist eine Komponente des VM-Pool-Verwaltungssystems 200, die konfiguriert wird, um virtuelle Maschinen zu verwalten und zu starten. Der VM-Pool-Verwalter 210 ist für die Ressourcenverwaltung der virtuellen Maschinen zuständig. Er kann eine Liste verwalten, die angibt, welche der angegebenen Anwendungen 250 auf welchen der Basis-VMs 233 ausgeführt werden. Zum Beispiel kann die Liste einen Eintrag haben, der angibt, dass Navigations-Software auf navigationsspezifischen virtuellen Maschinen läuft, und einen weiteren Eintrag, der angibt, dass Nicht-Benutzerschnittstellen-Anwendungen auf virtuellen Maschinen laufen, die für Nicht-Benutzerschnittstellen spezifisch sind.
Der VM-Pool-Verwalter 210 kann eine Reihe von VM-Verwaltungsdienstprogrammen ausführen. Diese Dienstprogramme enthalten zum Beispiel Funktionen, die virtuelle Maschinen erzeugen, löschen, in einen Schlafzustand versetzen und aufwecken. Die Dienstprogramme können auch eine Liste verwalten, die Anwendungen mit virtuellen Maschinen abgleicht.
Das VM-Pool-Manifest 220 ist eine Komponente des VM-Pool-Verwaltungssystems 200, die konfiguriert wird, um anfängliche VM-Einrichtungsanforderungen bereitzustellen. Das VM-Pool-Manifest 220 kann eine anfängliche Anzahl der Basis-VMs 233 enthalten, die in den VM-Pool 230 aufgenommen werden sollen. So kann die anfängliche Anzahl zum Beispiel angeben, dass beim Start sieben Basis-VMs 233 benötigt werden. Zusätzlich kann das VM-Pool-Manifest 220 die Anzahl der Basis-VMs 233 enthalten, die den Ressourcen 235 zugeordnet werden sollen.
Bei manchen Ausführungsformen gibt das VM-Pool-Manifest 220 eine Zuordnung der Ressourcen 235 auf Grundlage einer Ressourcendefinition an. Eine Ressourcendefinition definiert die Art von benötigten Ressourcen auf Grundlage der Art von Anwendung, die in die virtuelle Maschine 233 geladen wird. So kann eine Ressourcendefinition zum Beispiel die Ressourcen angeben, die für einen Anzeigepuffer benötigt werden. Ein Anzeigepuffer kann angeben, dass eine Anwendung die Verwendung einer Benutzerschnittstelle benötigt. Anwendungen, die Benutzerschnittstellen benötigen können, können zum Beispiel Navigation, Radio, Systemeinstellungen, Tachometer und dergleichen enthalten. Eine weitere Ressourcendefinition kann angeben, dass ein Anzeigepuffer nicht verwendet wird, was darauf hindeuten kann, dass für eine bestimmte Anwendung weniger Ressourcen benötigt werden. Diese Arten von Anwendungen können hintergrundbezogene Anwendungen sein, die eine Bordeinheit 105 während des Betriebs eines Fahrzeugs 100 verwenden kann.
Bei manchen Ausführungsformen enthält das VM-Pool-Manifest 220 eine Standard-Umgebungsressourcenzuweisung. Die Standard-Umgebungsressourcenzuweisung kann eine Standardzuordnung von Ressourcen enthalten, wenn für eine bestimmte virtuelle Maschine keine Ressourcendefinition definiert wird. Die Standard-Ressourcenzuweisung kann die Menge an Arbeitsspeicher, Speicher und CPU-Nutzung angeben, die einer Standard-Basis-VM 233 zugeordnet werden soll.
Bei manchen Ausführungsformen enthält das VM-Manifest 220 einen Parameter, der einen Schwellenwert von Anwendungen angibt, die eine Bordeinheit 105 zu einem beliebigen Zeitpunkt ausführen kann. Die Schwellenwert kann auf den Ressourcen beruhen, die der Bordeinheit 105 zur Verfügung stehen, und kann durch das VM-Pool-Verwaltungssystem 200 verwaltbar sein.
Der VM-Pool 230 ist eine Komponente des VM-Pool-Verwaltungssystems 200, die konfiguriert wird, um die Basis-VMs 233 zu speichern. Der VM-Pool 230 kann jeder beliebige Speicher sein, der in der Lage ist, Software zu speichern. Bei manchen Ausführungsformen speichert der VM-Pool 230 eine einzige virtuelle Maschine, die durch den VM-Pool-Verwalter 210 konfiguriert werden kann. Der VM-Pool 230 kann jede beliebige Anzahl von unterschiedlichen Basis-VMs 233 speichern, die durch den VM-Pool-Verwalter 210 konfiguriert werden können.
Die Basis-VMs 233 sind Komponenten des VM-Pool-Verwaltungssystems 200, die konfiguriert werden, um die Leistung einer Einheit (z.B. eines Computers) nachzuahmen. Die Basis-VMs 233 können aus dem VM-Pool 230 abgerufen werden. Die Basis-VMs 233 enthalten die Ressourcen 235, die benötigt werden, um die Basis-VMs 233 zu betreiben. Die Ressourcen enthalten zum Beispiel die Menge an Arbeitsspeicher, Speicher und CPU-Nutzung, die durch die Basis-VMs 233 benötigt wird. Zusätzlich können die Basis-VMs 233 auch ein Kernprogrammpaket enthalten, das in die Basis-VMs 233 geladen wird, wenn sie in dem VM-Pool 230 gestartet werden. Das Kernprogrammpaket kann ein Basisbetriebssystem bereitstellen, das benötigt wird, um die Anwendungen 250 sowie verschiedene Anwendungskomponenten, die in den Basis-VMs 233 enthalten sind, zu unterstützen und auszuführen.
Bei manchen Ausführungsformen enthalten die Basis-VMs 233 einen Client, der einem Server entspricht. Der Client kann über die Basis-VMs 233 mit dem Server Daten austauschen, um gemäß den verschiedenen Konfigurationsdefinitionen, die in dem VM-Pool-Manifest 220 enthalten sind, eine VM-Instanz zu erzeugen, zu klonen oder anderweitig darauf zuzugreifen.
Der Anwendungslebenszyklus-Verwalter 240 ist eine Komponente des VM-Pool-Verwaltungssystems 200, die konfiguriert wird, um den Lebenszyklus der Anwendungen 250 zu verwalten. Der Anwendungslebenszyklus-Verwalter 240 kann anfordern, dass eine Anwendung in eine Basis-VM 233 geladen wird. Zusätzlich kann der Anwendungslebenszyklus-Verwalter 240 ermitteln, welche Anwendungen der Reihenfolge nach geladen werden. Bei manchen Ausführungsformen fordert der Anwendungslebenszyklus-Verwalter 240 an, dass zusätzliche Basis-VMs 233 zu dem VM-Pool 230 hinzugefügt werden. Zum Beispiel können zahlreiche Anwendungen 250 in Betrieb sein, und um eine Verlangsamung des Betriebs zu vermeiden, kann der Anwendungslebenszyklus-Verwalter 240 anfordern, dass im Wartezustand befindlichen Basis-VMs 233 Ressourcen zugeordnet und Kernprogrammpakete in sie geladen werden. Außerdem können zusätzliche Basis-VMs 233 innerhalb des VM-Pools 230 gestartet und in eine Wartezustandskonfiguration versetzt werden. Diese Basis-VMs 233 haben möglicherweise keine zugewiesenen Ressourcen bzw. keine zugewiesene Programmlogik.
Der Anwendungslogik-Injektionsverwalter 244 ist eine Komponente des Anwendungslebenszyklus-Verwalters 240, die konfiguriert wird, um eine spezifische Anwendungslogik in die Basis-VMs 233 zu laden. Der Anwendungslogik-Injektionsverwalter 244 kann die Anwendung 250 identifizieren, die in eine Basis-VM 233 geladen werden soll, und anwendungsspezifische Informationen laden, um die Ausführung der Anwendung 250 zu ermöglichen. So können zum Beispiel Anwendungsklassen geladen und Injektionspunkte mit Rezeptoren in der Basis-VM 233 verknüpft werden.
Der Anwendungsressourcen-Zuweiser 248 ist eine Komponente des Anwendungslebenszyklus-Verwalters 240, die konfiguriert wird, um Ressourcen, die durch eine Anwendung 250 benötigt werden, einer virtuellen Maschine 233 zuzuordnen. Der Anwendungsressourcen-Zuweiser 248 kann die anfänglichen Ressourcen, die einer Basis-VM 233 zugeordnet werden, mit der Ressourceninformation 251 einer Anwendung 250 vergleichen, die in die virtuelle Maschine 233 geladen wird. Wenn sich die Ressourcen 235 unterscheiden, kann der Anwendungsressourcen-Zuweiser 248 Ressourcen der virtuellen Maschine 233 neu zuordnen. Zum Beispiel kann eine Basis-VM 233 50 Megabyte Speicher enthalten, und eine in die Basis-VM 233 geladene Anwendung 250 benötigt 65 Megabyte Speicher, woraufhin der Anwendungsressourcen-Zuweiser 248 der Basis-VM 250 mindestens 65 Megabyte Speicher neu zuordnen kann, damit die Anwendung geladen und ausgeführt werden kann.
Wenn die anfänglichen Ressourcen auf Grundlage der Ressourceninformation 251 genügend Ressourcen für eine Anwendung 250 bereitstellen, ordnet der Anwendungsressourcen-Zuweiser 248 bei manchen Ausführungsformen keine Ressourcen neu zu. Wenn die anfänglichen Ressourcen auf Grundlage der Ressourceninformation 251 genügend Ressourcen für eine Anwendung 250 bereitstellen, evaluiert der Anwendungsressourcen-Zuweiser 248 bei manchen Ausführungsformen die Ressourcen und hebt die Zuordnung etwaiger unnötiger Ressourcen auf. Wenn die anfänglichen Ressourcen zum Beispiel 200 Kilobyte Arbeitsspeicher enthalten und die Anwendung 250 nur 100 Kilobyte Arbeitsspeicher benötigt, kann der Anwendungsressourcen-Zuweiser 248 die Zuordnung von maximal 100 Kilobyte Arbeitsspeicher zu der virtuellen Maschine 233 aufheben.
Die Anwendungen 250 sind Software des VM-Pool-Verwaltungssystems 200, die durch eine Bordeinheit 105 ausgeführt werden können. Die Anwendungen enthalten Merkmale wie Telematikdienste, Straßeninformationen, Verkehrsinformationen, Wetterinformationen, Flottenverwaltung, Gesundheitsuntersuchungen, Nothilfe, Musik/Video, Versicherung, Nachrichten und Infotainment. Jede Anwendung 250 enthält zusätzlich eine Ressourceninformation 251, die sich auf die Anwendung 250 bezieht. Die Ressourceninformation 251 kann die Anzahl von Ressourcen enthalten, die benötigt werden, um eine bestimmte Anwendung 250 auszuführen und zu betreiben. Zum Beispiel benötigt eine Anwendung 250, die Wetterinformationen bereitstellt, eine bestimmte Menge an Arbeitsspeicher, Speicher und CPU-Nutzung, die die Ressourceninformation 251 speichern kann.
Der Anwendungspaket-Verwalter 260 ist eine Komponente des VM-Pool-Verwaltungssystems 200, die konfiguriert wird, um die durch das VM-Pool-Verwaltungssystem 200 bereitgestellten Anwendungen 250 zu installieren und zu aktualisieren. Der Anwendungspaket-Verwalter 260 kann den Prozess eines Installierens, Aktualisierens, Konfigurierens und Entfernens der Anwendungen 250 aus einer Bordeinheit 105 automatisieren. Der Anwendungspaket-Verwalter 260 kann Datenpakete verarbeiten, bei denen es sich um Verteilungen von Software und Daten in Archivdateien handelt. Datenpakete können Metadaten enthalten, z.B. den Namen einer Anwendung 250, eine Beschreibung ihres Zwecks, eine Versionsnummer, einen Hersteller, eine Prüfsumme und eine Liste von Abhängigkeiten, die notwendig sind, um die Anwendung 250 einwandfrei auszuführen (z.B. die Ressourceninformation 251). Bei der Installation können Metadaten in einer lokalen Datenpaket-Datenbank gespeichert werden. Der Anwendungspaket-Verwalter 260 kann eine Datenbank mit Abhängigkeiten und Versionsinformationen der Anwendung 250 verwalten, um Software-Konflikte und fehlende Voraussetzungen zu verhindern.
Es wird darauf verwiesen, dass 2 die repräsentativen Hauptkomponenten eines beispielhaften VM-Pool-Verwaltungssystems 200 darstellen soll. Allerdings können bei manchen Ausführungsformen einzelne Komponenten eine größere oder geringere Komplexität als in 2 gezeigt haben, andere oder zusätzliche Komponenten als die in 2 gezeigten können vorhanden sein, und die Anzahl, Art und Konfiguration solcher Komponenten kann variieren.
3 ist ein Ablaufplan, der einen Prozess 300 eines Vorab-Poolings von VM-Komponenten vor dem Anwendungsstart gemäß Ausführungsformen der vorliegenden Offenbarung veranschaulicht. Der Prozess 300 beginnt, indem der VM-Pool-Verwalter 210 bei der Initiierung des VM-Pool-Verwaltungssystems 200 das VM-Pool-Manifest 220 liest. Dies wird in einem Schritt 310 veranschaulicht. Der VM-Pool-Verwalter 210 kann die anfänglichen Anforderungen der virtuellen Maschine 233 lesen. Diese Anforderungen können zum Beispiel eine anfängliche Anzahl der Basis-VMs 233, die in den VM-Pool 230 aufgenommen werden sollen, eine Zuordnung der Ressourcen 235 für jede virtuelle Maschine 233 auf Grundlage einer Ressourcendefinition, eine Standard-Umgebungsressourcenzuweisung und einen Parameter enthalten, der eine maximale Anzahl von Anwendungen angibt, die eine Bordeinheit 105 zu einem beliebigen Zeitpunkt ausführen kann.
Der VM-Pool-Verwalter 210 startet die Basis-VMs 233 in dem VM-Pool 230, wie dies in dem VM-Pool-Manifest 220 angegeben wird. Dies wird in einem Schritt 320 veranschaulicht. Der VM-Pool 230 kann jede beliebige Anzahl von unterschiedlichen Basis-VMs 233 speichern, die durch den VM-Pool-Verwalter 210 konfiguriert werden können. Beim Start weisen die Basis-VMs 233 keine Ressourcenzuordnung und keine geladenen Kernprogrammpakete auf. Bei manchen Ausführungsformen werden die Basis-VMs 233 gemäß einem Zeitplan gestartet, der durch das VM-Pool-Manifest 220 angegeben wird. So kann das VM-Pool-Manifest 220 zum Beispiel angeben, dass zwölf Basis-VMs 233 bei der Initiierung gestartet werden und dass nach einer vorgegebenen Zeitspanne weitere fünf Basis-VMs 233 gestartet werden sollen. Diese Abfolge von vorgegebenen Startvorgängen der Basis-VMs 233 kann so häufig stattfinden, wie dies die Konfiguration des VM-Pool-Manifests 220 vorsieht.
Der VM-Pool-Verwalter 210 ordnet die anfänglichen Ressourcen 235 einem Teil der Basis-VMs 233 zu, die in dem Schritt 320 gestartet werden. Dies wird in einem Schritt 330 veranschaulicht. Die Basis-VMs 233, die den Ressourcen 235 zugeordnet werden, können durch das VM-Pool-Manifest 220 vorgegeben werden. Die Anzahl der Basis-VMs 233, denen ebenfalls Ressourcen zugeordnet werden, kann auch eine optimierte Anzahl auf Grundlage der Anzahl der Anwendungen 250 sein, die beim Start durch ein Fahrzeug 100 benötigt werden. Diese Anwendungen enthalten zum Beispiel Telematikdienste, Straßeninformationen, Verkehrsinformationen, Wetterinformationen, Flottenverwaltung, Gesundheitsuntersuchungen, Nothilfe, Musik/Video, Versicherung, Nachrichten und Infotainment. Der verbleibende Teil der Basis-VMs 233 kann so lange in eine Wartekonfiguration versetzt werden, bis er benötigt wird.
Indem die Basis-VMs 233 in eine Wartekonfiguration versetzt werden, muss das VM-Pool-Verwaltungssystem 200 keine zusätzliche Zeit für das Starten einer virtuellen Maschine 233 aufwenden, wenn eine Anwendung 250 gestartet werden muss. Zusätzlich werden womöglich nicht alle Basis-VMs 233, die den Ressourcen 235 zugeordnet werden, sofort einer Anwendung zugewiesen und können stattdessen während des Betriebs der Bordeinheit 105 als Puffer dienen. Wenn die Basis-VMs 233 durch die Anwendungen 250 angefordert und verwendet werden, können mehr virtuelle Maschinen in dem VM-Pool 230 gestartet werden, um einen Puffer aufrechtzuerhalten und den Startprozess einer Anwendung 250 zu beschleunigen.
Der Anwendungspaket-Verwalter 260 lädt Kernprogrammpakete in den Teil der Basis-VMs 233, der den Ressourcen 235 zugeordnet wird. Dies wird in einem Schritt 340 veranschaulicht. Die Kernprogrammpakete können eine Java-VM-Umgebung ohne Anwendungslogik enthalten. Andere Kernprogrammpakete enthalten zum Beispiel VM-Basiscode, Klassenbibliotheken (z.B. Java), einen API-(Application Programming Interface, Anwendungsprogrammschnittstelle)Dienst und Software für die Verwaltung eines Benutzerschnittstellen-Lebenszyklus. Die Kernprogrammpakete können Rezeptoren enthalten, die für Shells stehen können, in die eine Anwendungslogik geladen wird. Sobald einer virtuellen Maschine 233 die Ressourcen 235 zugeordnet und Kernprogrammpakete in sie geladen wurden, wird sie in eine Bereitschaftskonfiguration versetzt, kann einer Anwendung zugewiesen werden, und eine Anwendung kann in sie geladen werden.
Der Anwendungslebenszyklus-Verwalter 240 weist einer Anwendung 250 eine Basis-VM 233 zu, die sich in einer Bereitschaftskonfiguration befindet. Dies wird in einem Schritt 350 veranschaulicht. Bei manchen Ausführungsformen ermittelt der Anwendungslebenszyklus-Verwalter 240, welche Anwendungen der Reihenfolge nach geladen werden. Die Reihenfolge, in der der Anwendungslebenszyklus-Verwalter 240 eine Anwendung 250 auswählt und zuweist, kann auf Grundlage einer Dringlichkeit erfolgen, mit der eine Anwendung 250 durch eine Bordeinheit 105 benötigt wird. Zum Beispiel kann einer Anwendung 250, die beim Start eines Fahrzeugs 100 eine Systemdiagnose bereitstellt, vor einer Anwendung 250, die einem Passagier ein Infotainment bereitstellt, eine virtuelle Maschine 233 zugewiesen werden.
Bei manchen Ausführungsformen weist der Anwendungslebenszyklus-Verwalter 250 auf Grundlage der Anwendungsart der gestarteten Anwendung 250 eine Anwendung einer Basis-VM 233 in einer Bereitschaftskonfiguration zu. Zum Beispiel kann eine Anwendung 250, die keine Benutzerschnittstelle benötigt, zuerst gestartet werden, da die Ressourceninformation 251 der Anwendung 250 mit derjenigen der anfänglichen Ressourcen 235 übereinstimmt, die der Basis-VM 233 zugeordnet werden. Somit müssen der virtuellen Maschine 233 keine zusätzlichen Ressourcen 235 neu zugeordnet werden, und die Anwendung 250 kann schneller als eine Anwendung 250 gestartet werden, die womöglich zusätzliche Ressourcen benötigt.
Der Anwendungslogik-Injektionsverwalter 244 startet die Anwendung 250 in der Basis-VM 233. Dies wird in einem Schritt 360 veranschaulicht. Eine Anwendungslogik enthält zum Beispiel anwendungsspezifische Klassen, Verfahren und zusätzlichen Code. Der Anwendungslogik-Injektionsverwalter 244 kann eine Anwendungslogik, die sich auf die Anwendung 250 bezieht, in die virtuelle Maschine 233 laden. Zusätzlich können die Injektionspunkte mit den Rezeptoren verknüpft werden, die in der virtuellen Maschine 233 enthalten sind und mit den Kernprogrammpaketen geladen wurden.
Bei manchen Ausführungsformen analysiert der Anwendungsressourcen-Zuweiser 248 die Ressourceninformation 251 der Anwendung 250 und der anfänglichen Ressourcen 235, die der virtuellen Maschine 233 zugewiesen werden. Auf Grundlage der Analyse kann der Anwendungsressourcen-Zuweiser die Ressourcen 235 der virtuellen Maschine 233 neu zuweisen, um ein erfolgreiches Starten der Anwendung zu ermöglichen. Wenn die anfänglichen Ressourcen 235 zum Beispiel 45 Kilobyte verfügbaren Arbeitsspeicher enthalten und die gestartete Anwendung 250 100 Kilobyte Arbeitsspeicher benötigt, kann der Anwendungsressourcen-Zuweiser 248 der virtuellen Maschine 233 zusätzlichen Arbeitsspeicher neu zuordnen, sodass die Anwendung 250 einwandfrei starten kann.
Bei manchen Ausführungsformen analysiert der Anwendungsressourcen-Zuweiser 248 die Ressourceninformation 251 der Anwendung 250 und der anfänglichen Ressourcen 235, die der virtuellen Maschine 233 zugewiesen werden. Auf Grundlage der Analyse kann der Anwendungsressourcen-Zuweiser die nicht benötigten Ressourcen 235 wieder einem Ressourcen-Pool zuweisen. Sobald die Anwendungslogik in die Anwendung 250 geladen wurde und Injektionspunkte verknüpft wurden, führt der Anwendungslebenszyklus-Verwalter 240 die Anwendung 250 aus. Dies wird in einem Schritt 370 veranschaulicht. Der Anwendungslebenszyklus-Verwalter 240 kann die Anwendung 250 während des Betriebs und der Ausführung überwachen und ermitteln, ob und wann die Anwendung 250 beendet werden soll
Unter Bezugnahme auf 4 wird ein allgemeines Blockschaubild eines Beispiel-Computersystems 400 (z.B. des VM-Pool-Verwaltungssystems 100) gezeigt, das gemäß Ausführungsformen der vorliegenden Offenbarung zum Realisieren eines oder mehrerer der hierin beschriebenen Verfahren, Werkzeuge und Module sowie aller damit in Verbindung stehenden Funktionen verwendet werden kann (z.B. unter Verwendung eines oder mehrerer Prozessorschaltkreise oder Computerprozessoren des Computers). Bei manchen Ausführungsformen können die Hauptkomponenten des Computersystems 400 einen oder mehrere Prozessoren 402, einen Arbeitsspeicher 404, eine Terminal-Schnittstelle 412, eine E/A(Eingabe/Ausgabe)-Einheitenschnittstelle 414, eine Speicherschnittstelle 416 und eine Netzwerkschnittstelle 418 aufweisen, die alle für eine komponentenübergreifende Datenübertragung über einen Arbeitsspeicherbus 403, einen E/A-Bus 408 und eine E/A-Busschnittstellen-Einheit 410 direkt oder indirekt im Datenaustausch gekoppelt werden können.
Das Computersystem 400 kann eine oder mehrere Universal-Zentraleinheiten (CPUs) 402-1, 402-2, 402-3 und 402-N enthalten, die hierin verallgemeinernd als der Prozessor 402 bezeichnet werden. Bei manchen Ausführungsformen kann das Computersystem 400 mehrere Prozessoren enthalten, die typisch für ein vergleichsweise großes System sind; bei anderen Ausführungsformen kann das Computersystem 400 alternativ allerdings ein System mit einer einzigen CPU sein. Jeder Prozessor 401 kann Anweisungen ausführen, die in dem Arbeitsspeicher 404 gespeichert werden, und kann eine oder mehrere Ebenen eines integrierten Caches enthalten.
Der Arbeitsspeicher 404 kann ein durch ein Computersystem lesbares Medium in Form eines flüchtigen Arbeitsspeichers wie z.B. eines Direktzugriffsspeichers 422 (RAM) oder eines Cache-Arbeitsspeichers 424 enthalten. Das Computersystem 400 kann des Weiteren andere entfernbare/nicht entfernbare, flüchtige/nicht flüchtige Computersystem-Speichermedien enthalten. Nur um ein Beispiel zu geben, kann ein Speichersystem 426 zum Lesen von und Schreiben auf ein nicht entfernbares, nicht flüchtiges magnetisches Medium wie z.B. eine „Festplatte“ bereitgestellt werden. Obwohl hierin nicht gezeigt, können ein Magnetplattenlaufwerk zum Lesen von und Schreiben auf eine entfernbare, nicht flüchtige Magnetplatte (z.B. eine „Diskette“) sowie ein optisches Plattenlaufwerk zum Lesen von oder Schreiben auf eine entfernbare, nicht flüchtige optische Platte wie z.B. ein CD-ROM, ein DVD-ROM oder ein anderes optisches Medium bereitgestellt werden. Zusätzlich kann der Arbeitsspeicher 404 einen Flash-Arbeitsspeicher wie z.B. einen Flash-Speicher-Stick- oder ein Flash-Laufwerk aufweisen. Arbeitsspeichereinheiten können durch eine oder mehrere Datenmedienschnittstellen mit dem Arbeitsspeicherbus 403 verbunden werden. Der Arbeitsspeicher 404 kann mindestens ein Programmprodukt mit einem Satz von (z.B. mindestens einem) Programmmodulen enthalten, die konfiguriert werden, um die Funktionen verschiedener Ausführungsformen auszuführen.
Obwohl der Arbeitsspeicherbus 403 in 4 als eine einzelne Busstruktur gezeigt wird, die einen direkten Datenübertragungspfad zwischen den Prozessoren 402, dem Arbeitsspeicher 404 und der E/A-Busschnittstelle 410 bereitstellt, kann der Arbeitsspeicherbus 403 bei manchen Ausführungsformen mehrere unterschiedliche Busse und Datenübertragungspfade aufweisen, die in einer beliebigen Weise angeordnet werden können, z.B. als Punkt-zu-Punkt-Verbindungen in hierarchischen, Stern- oder Netzwerk-Konfigurationen, als mehrere hierarchische Busse, parallele und redundante Pfade oder als jede andere geeignete Art von Konfiguration. Obwohl die E/A-Busschnittstelle 410 und der E/A-Bus 408 als jeweils einzelne Einheiten gezeigt werden, kann das Computersystem 400 darüber hinaus bei manchen Ausführungsformen mehrere E/A-Busschnittstellen-Einheiten, mehrere E/-A-Busse oder beides enthalten. Obwohl mehrere E/A-Schnittstelleneinheiten gezeigt werden, die den E/A-Bus 408 von verschiedenen Datenübertragungspfaden zu den verschiedenen E/A-Einheiten trennen, können bei anderen Ausführungsformen des Weiteren einige oder alle der E/A-Einheiten direkt mit einem oder mehreren E/A-Systembussen verbunden werden.
Bei manchen Ausführungsformen kann das Computersystem 400 ein Mehrbenutzer-Mainframe-Computersystem, ein Einzelbenutzer-System oder ein Server-Computer oder eine ähnliche Einheit sein, die nur eine geringfügige oder keine direkte Benutzerschnittstelle aufweist, aber Anforderungen von anderen Computersystemen (Clients) empfängt. Des Weiteren kann das Computersystem 400 bei manchen Ausführungsformen als ein Desktop Computer, tragbarer Computer, Laptop oder Notebook Computer, Tablet Computer, Taschencomputer, Telefon, Smartphone, als Netzwerk-Switches oder Router oder als jede andere geeignete Art von elektronischer Einheit realisiert werden.
Es wird darauf verwiesen, dass 4 die repräsentativen Hauptkomponenten eines beispielhaften Computersystems 400 darstellen soll. Allerdings können bei manchen Ausführungsformen einzelne Komponenten eine größere oder geringere Komplexität als in 4 gezeigt haben, andere oder zusätzliche Komponenten als die in 4 gezeigten können vorhanden sein, und die Anzahl, Art und Konfiguration solcher Komponenten kann variieren.
Eines oder mehrere Programme/Dienstprogramme 428 mit jeweils mindestens einem Satz von Programmmodulen 430 (z.B. dem VM-Pool-Verwaltungssystem 100) können in dem Arbeitsspeicher 404 gespeichert werden. Die Programme/Dienstprogramme 428 können einen (auch als einen VM-Überwacher bezeichneten) Hypervisor, ein oder mehrere Betriebssysteme, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten enthalten. Jedes der Betriebssysteme, des einen oder der mehreren Anwendungsprogramme, der anderen Programmmodule und der Programmdaten oder einer Kombination hiervon können jeweils eine Realisierung einer Netzwerkumgebung enthalten. Die Programme 428 und/oder Programmmodule 430 führen im Allgemeinen die Funktionen oder Verfahrensweisen verschiedener Ausführungsformen durch.
Es sei klargestellt, dass das Umsetzen der hierin angeführten Lehren nicht auf eine Cloud-Computing-Umgebung beschränkt ist, obwohl diese Offenbarung eine ausführliche Beschreibung von Cloud Computing enthält. Vielmehr können Ausführungsformen der vorliegenden Erfindung gemeinsam mit jeder beliebigen Art von jetzt bekannter oder später entwickelter Datenverarbeitungsumgebung umgesetzt werden.
Cloud Computing ist ein Dienstbereitstellungsmodell zum Ermöglichen eines problemlosen bedarfsgesteuerten Netzwerkzugriffs auf einen gemeinsam genutzten Pool von konfigurierbaren Datenverarbeitungsressourcen (z.B. Netzwerke, Netzwerkbandbreite, Server, Verarbeitung, Hauptspeicher, Speicher, Anwendungen, virtuelle Maschinen und Dienste), die mit minimalem Verwaltungsaufwand bzw. minimaler Interaktion mit einem Anbieter des Dienstes schnell bereitgestellt und freigegeben werden können. Dieses Cloud-Modell kann mindestens fünf Eigenschaften, mindestens drei Dienstmodelle und mindestens vier Einsatzmodelle enthalten.
Bei den Eigenschaften handelt es sich um die Folgenden:
On-Demand Self-Service: Ein Cloud-Nutzer kann einseitig automatisch nach Bedarf für Datenverarbeitungsfähigkeiten wie Server-Zeit und Netzwerkspeicher sorgen, ohne dass eine menschliche Interaktion mit dem Anbieter der Dienste erforderlich ist.
Broad Network Access: Es sind Fähigkeiten über ein Netzwerk verfügbar, auf die durch Standardmechanismen zugegriffen wird, die die Verwendung durch heterogene Thin- oder Thick-Client-Plattformen (z.B. Mobiltelefone, Laptops und PDAs) unterstützen.
Resource Pooling: Die Datenverarbeitungsressourcen des Anbieters werden zusammengeschlossen, um mehreren Nutzern unter Verwendung eines Multi-Tenant-Modells zu dienen, wobei verschiedene physische und virtuelle Ressourcen dynamisch nach Bedarf zugewiesen und neu zugewiesen werden. Es gibt eine gefühlte Standortunabhängigkeit, da der Nutzer allgemein keine Kontrolle bzw. Kenntnis über den genauen Standort der bereitgestellten Ressourcen hat, aber in der Lage sein kann, einen Standort auf einer höheren Abstraktionsebene festzulegen (z.B. Land, Staat oder Rechenzentrum).
Rapid Elasticity: Fähigkeiten können für eine schnelle horizontale Skalierung (Scale-out) schnell und elastisch bereitgestellt werden, in einigen Fällen auch automatisch, und für ein schnelles Scale-in schnell freigegeben werden. Für den Nutzer erscheinen die für das Bereitstellen verfügbaren Fähigkeiten häufig unbegrenzt und sie können jederzeit in jeder beliebigen Menge gekauft werden.
Measured Service: Cloud-Systeme steuern und optimieren die Verwendung von Ressourcen automatisch, indem sie eine Messfähigkeit auf einer gewissen Abstraktionsebene nutzen, die für die Art von Dienst geeignet ist (z.B. Speicher, Verarbeitung, Bandbreite sowie aktive Benutzerkonten). Der Ressourcenverbrauch kann überwacht, gesteuert und gemeldet werden, wodurch sowohl für den Anbieter als auch für den Benutzer des verwendeten Dienstes Transparenz bereitgestellt wird.
Bei den Dienstmodellen handelt es sich um die Folgenden:
Software as a Service (SaaS): Die dem Nutzer bereitgestellte Fähigkeit besteht darin, die in einer Cloud-Infrastruktur laufenden Anwendungen des Anbieters zu verwenden. Die Anwendungen sind über eine Thin-Client-Schnittstelle wie einen Web-Browser (z.B. auf dem Web beruhende eMail) von verschiedenen Client-Einheiten her zugänglich. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter das Netzwerk, Server, Betriebssysteme, Speicher bzw. sogar einzelne Anwendungsfähigkeiten, mit der möglichen Ausnahme von eingeschränkten nutzerspezifischen Anwendungskonfigurationseinstellungen.
Platform as a Service (PaaS): Die dem Nutzer bereitgestellte Fähigkeit besteht darin, durch einen Nutzer erstellte bzw. erhaltene Anwendungen, die unter Verwendung von durch den Anbieter unterstützten Programmiersprachen und Tools erstellt wurden, in der Cloud-Infrastruktur einzusetzen. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, darunter Netzwerke, Server, Betriebssysteme bzw. Speicher, hat aber die Kontrolle über die eingesetzten Anwendungen und möglicherweise über Konfigurationen für Application Hosting Environment.
Infrastructure as a Service (laaS): Die dem Nutzer bereitgestellte Fähigkeit besteht darin, Verarbeitung, Speicher, Netzwerke und andere grundlegende Datenverarbeitungsressourcen bereitzustellen, wobei der Nutzer in der Lage ist, beliebige Software einzusetzen und auszuführen, zu der Betriebssysteme und Anwendungen gehören können. Der Nutzer verwaltet bzw. steuert die zugrunde liegende Cloud-Infrastruktur nicht, hat aber die Kontrolle über Betriebssysteme, Speicher, eingesetzte Anwendungen und möglicherweise eine eingeschränkte Kontrolle über ausgewählte Netzwerkkomponenten (z.B. Host-Firewalls).
Bei den Einsatzmodellen handelt es sich um die Folgenden:
Private Cloud: Die Cloud-Infrastruktur wird einzig und allein für eine Organisation betrieben. Sie kann durch die Organisation oder einen Dritten verwaltet werden und kann sich in den eigenen Räumen oder in fremden Räumen befinden.
Community Cloud: Die Cloud-Infrastruktur wird von mehreren Organisationen gemeinsam genutzt und unterstützt eine spezielle Benutzergemeinschaft, die gemeinsame Angelegenheiten hat (z.B. Zielsetzung, Sicherheitsanforderungen, Richtlinien sowie Überlegungen bezüglich der Einhaltung von Vorschriften). Sie kann durch die Organisationen oder einen Dritten verwaltet werden und sich in den eigenen Räumen oder in fremden Räumen befinden.
Public Cloud: Die Cloud-Infrastruktur wird der allgemeinen Öffentlichkeit oder einer großen Industriegruppe zur Verfügung gestellt und gehört einer Cloud-Dienste verkaufenden Organisation.
Hybrid Cloud: Die Cloud-Infrastruktur ist eine Zusammensetzung aus zwei oder mehreren Clouds (privat, Nutzergemeinschaft oder öffentlich), die zwar einzelne Einheiten bleiben, aber durch eine standardisierte oder proprietäre Technologie miteinander verbunden sind, die Daten- und Anwendungsportierbarkeit ermöglicht (z.B. Cloud-Zielgruppenverteilung für den Lastenausgleich zwischen Clouds).
Eine Cloud-Computing-Umgebung ist dienstorientiert mit Fokus auf Statusunabhängigkeit, geringer Kopplung, Modularität und semantischer Interoperabilität. Im Mittelpunkt des Cloud Computing steht eine Infrastruktur, die ein Netzwerk aus zusammengeschalteten Knoten enthält.
Unter Bezugnahme auf 5 wird eine veranschaulichende Cloud-Computing-Umgebung 500 dargestellt. Wie gezeigt, enthält die Cloud-Computing-Umgebung 500 einen oder mehrere Cloud-Computing-Knoten 510, mit denen von Cloud-Nutzern verwendete lokale Datenverarbeitungseinheiten wie ein elektronischer Assistent (PDA, Personal Digital Assistant) oder ein Mobiltelefon 520-1, ein Desktop Computer 520-2, ein Laptop Computer 520-3 und/oder ein Automobil-Computer-System 520-4 Daten austauschen können. Die Knoten 510 können miteinander Daten austauschen. Sie können physisch oder virtuell in einem oder mehreren Netzwerken wie Private, Community, Public oder Hybrid Clouds zusammengefasst werden (nicht gezeigt), wie vorstehend beschrieben wurde, oder aber in einer Kombination daraus. Dies ermöglicht es der Cloud-Computing-Umgebung 500, Infrastruktur, Plattformen und/oder Software als Dienst anzubieten, für die ein Cloud-Nutzer keine Ressourcen auf einer lokalen Datenverarbeitungseinheit vorhalten muss. Es sei darauf hingewiesen, dass die Arten der in 5 gezeigten Datenverarbeitungseinheiten 520-1 bis 520-4 lediglich veranschaulichend sein sollen und dass die Datenverarbeitungsknoten 510 und die Cloud-Computing-Umgebung 500 über eine beliebige Art von Netzwerk und/oder über eine beliebige Art von über ein Netzwerk aufrufbarer Verbindung (z.B. unter Verwendung eines Web-Browsers) mit einer beliebigen Art von computergestützter Einheit Daten austauschen können.
Unter Bezugnahme auf 6 wird ein Satz von funktionalen Abstraktionsschichten 600 gezeigt, die durch die Cloud-Computing-Umgebung 500 (5) bereitgestellt werden. Es sollte von vornherein klar sein, dass die in 6 gezeigten Komponenten, Schichten und Funktionen lediglich veranschaulichend sein sollen und Ausführungsformen der Erfindung nicht darauf beschränkt sind. Wie dargestellt, werden die folgenden Schichten und entsprechenden Funktionen bereitgestellt:
Eine Hardware- und Software-Schicht 610 enthält Hardware- und Software-Komponenten. Zu Beispielen für Hardware-Komponenten gehören: Mainframe Computer 611; auf der RISC(Reduced Instruction Set Computer)-Architektur beruhende Server 612; Server 613; Blade-Server 614; Speichereinheiten 615; und Netzwerke sowie Netzwerkkomponenten 616. Bei einigen Ausführungsformen enthalten Software-Komponenten eine Netzwerk-Anwendungsserver-Software 617 und eine Datenbank-Software 618.
Eine Virtualisierungsschicht 620 stellt eine Abstraktionsschicht bereit, welche die folgenden Beispiele für virtuelle Einheiten zur Verfügung stellen kann: virtuelle Server 621; virtueller Speicher 622; virtuelle Netzwerke 623, einschließlich virtueller privater Netzwerke; virtuelle Anwendungen und Betriebssysteme 624; sowie virtuelle Clients 625.
In einem Beispiel kann eine Verwaltungsschicht 630 die nachfolgend beschriebenen Funktionen bereitstellen. Eine Ressourcen-Bereitstellung 631 stellt die dynamische Beschaffung von Datenverarbeitungsressourcen sowie anderen Ressourcen bereit, die zum Durchführen von Aufgaben innerhalb der Cloud-Computing-Umgebung verwendet werden. Ein Messen und eine Preisfindung 632 stellen die Kostenverfolgung beim Verwenden von Ressourcen innerhalb der Cloud-Computing-Umgebung sowie die Abrechnung oder Rechnungsstellung für den Verbrauch dieser Ressourcen bereit. In einem Beispiel können diese Ressourcen Anwendungs-Software-Lizenzen aufweisen. Eine Sicherheit stellt die Identitätsüberprüfung für Cloud-Nutzer und Aufgaben sowie Schutz für Daten und andere Ressourcen bereit. Ein Benutzerportal 633 stellt Nutzern und Systemadministratoren den Zugang zu der Cloud-Computing-Umgebung bereit. Eine Verwaltung des Dienstumfangs 634 stellt die Zuordnung und Verwaltung von Cloud-Computing-Ressourcen bereit, sodass die benötigten Dienstziele erreicht werden. Ein Planen und Erfüllen von Vereinbarungen zum Dienstumfang (Service Level Agreement, SLA) 635 stellt die Vorab-Anordnung und die Beschaffung von Cloud-Computing-Ressourcen, für die eine zukünftige Anforderung vorausgesehen wird, gemäß einer SLA bereit.
Eine Arbeitslastenschicht 640 stellt Beispiele für die Funktionalität bereit, für die die Cloud-Computing-Umgebung verwendet werden kann. Beispiele für Auslastungen und Funktionen, die von dieser Schicht bereitgestellt werden können, lauten: Zuordnung und Navigation 641; Software-Entwicklung und Lebenszyklusverwaltung 642 (z.B. das VM-Pool-Verwaltungssystem 100); Bereitstellung von virtuellen Schulungen 643; Datenanalyseverarbeitung 644; Transaktionsverarbeitung 645; und z.B. das VM-Pool-Verwaltungssystem.
Bei der vorliegenden Erfindung kann es sich um ein System, ein Verfahren und/oder ein Computerprogrammprodukt mit einem beliebigen möglichen Grad an technischer Integration handeln. Das Computerprogrammprodukt kann ein computerlesbares Speichermedium (oder computerlesbare Speichermedien) mit darauf gespeicherten computerlesbaren Programmanweisungen enthalten, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Bei dem computerlesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch eine Anweisungsausführungseinheit behalten und speichern kann. Bei dem computerlesbaren Speichermedium kann es sich zum Beispiel um eine elektronische Speichereinheit, eine magnetische Speichereinheit, eine optische Speichereinheit, eine elektromagnetische Speichereinheit, eine Halbleiterspeichereinheit oder jede geeignete Kombination daraus handeln, ohne auf diese beschränkt zu sein. Zu einer nicht erschöpfenden Liste spezifischerer Beispiele des computerlesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein RAM, ein ROM, ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer CD-ROM, eine DVD (Digital Versatile Disc), ein Speicher-Stick, eine Diskette, eine mechanisch kodierte Einheit wie zum Beispiel Lochkarten oder erhabene Strukturen in einer Rille, auf denen Anweisungen gespeichert sind, und jede geeignete Kombination daraus. Ein computerlesbares Speichermedium soll in der Verwendung hierin nicht als flüchtige Signale an sich aufgefasst werden, wie zum Beispiel Funkwellen oder andere sich frei ausbreitende elektromagnetische Wellen, elektromagnetische Wellen, die sich durch einen Wellenleiter oder ein anderes Übertragungsmedium ausbreiten (z.B. durch ein Lichtwellenleiterkabel geleitete Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene computerlesbare Programmanweisungen können von einem computerlesbaren Speichermedium auf jeweilige Datenverarbeitungs-/ Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetzwerk und/oder ein drahtloses Netzwerk auf einen externen Computer oder eine externe Speichereinheit heruntergeladen werden. Das Netzwerk kann Kupferübertragungskabel, Lichtwellenübertragungsleiter, drahtlose Übertragung, Leitwegrechner, Firewalls, Vermittlungseinheiten, Gateway Computer und/oder Edge-Server aufweisen. Eine Netzwerkadapterkarte oder Netzwerkschnittstelle in jeder Datenverarbeitungs-/Verarbeitungseinheit empfängt computerlesbare Programmanweisungen aus dem Netzwerk und leitet die computerlesbaren Programmanweisungen zur Speicherung in einem computerlesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei computerlesbaren Programmanweisungen zum Ausführen von Arbeitsschritten der vorliegenden Erfindung kann es sich um Assembler-Anweisungen, ISA-Anweisungen (Instruction Set Architecture), Maschinenanweisungen maschinenabhängige Anweisungen, Mikrocode, Firmware-Anweisungen, zustandseinstellende Daten, Konfigurationsdaten für eine integrierte Schaltung oder sowohl um Quellcode als auch um Objektcode handeln, die in einer beliebigen Kombination aus einer oder mehreren Programmiersprachen geschrieben werden, darunter objektorientierte Programmiersprachen wie Smalltalk, C++ o.ä. sowie herkömmliche prozedurale Programmiersprachen wie die Programmiersprache „C“ oder ähnliche Programmiersprachen. Die computerlesbaren Programmanweisungen können vollständig auf dem Computer des Benutzers, teilweise auf dem Computer des Benutzers, als eigenständiges Software-Paket, teilweise auf dem Computer des Benutzers und teilweise auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Fall kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch eine beliebige Art Netzwerk verbunden sein, darunter ein lokales Netzwerk (LAN) oder ein Weitverkehrsnetzwerk (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). Bei manchen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, im Feld programmierbare Gatter-Arrays (Field-Programmable Gate Arrays, FPGA) oder programmierbare Logik-Arrays (Programmable Logic Arrays, PLA) die computerlesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der computerlesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung werden hierin unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es wird darauf hingewiesen, dass jeder Block der Ablaufpläne und/oder der Blockschaubilder sowie Kombinationen von Blöcken in den Ablaufplänen und/oder den Blockschaubildern mittels computerlesbarer Programmanweisungen ausgeführt werden können.
Diese computerlesbaren Programmanweisungen können einem Prozessor eines Computers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen ein Mittel zur Umsetzung der in dem Block oder den Blöcken des Ablaufplans und/oder des Blockschaubilds festgelegten Funktionen/Schritte erzeugen. Diese computerlesbaren Programmanweisungen können auch auf einem computerlesbaren Speichermedium gespeichert werden, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, sodass das computerlesbare Speichermedium, auf dem Anweisungen gespeichert werden, ein Herstellungsprodukt aufweist, darunter Anweisungen, die Aspekte der bzw. des in dem Block bzw. den Blöcken der Ablaufpläne und/oder Blockschaubilder angegebenen Funktion/Schritts umsetzen.
Die computerlesbaren Programmanweisungen können auch auf einen Computer, eine andere programmierbare Datenverarbeitungsvorrichtung oder eine andere Einheit geladen werden, um das Ausführen einer Reihe von Prozessschritten auf dem Computer bzw. der anderen programmierbaren Vorrichtung oder anderen Einheit zu verursachen, um einen computerrealisierten Prozess zu erzeugen, sodass die auf dem Computer, einer anderen programmierbaren Vorrichtung oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder Blockschaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und die Blockschaubilder in den Figuren veranschaulichen die Architektur, die Funktionalität und den Betrieb möglicher Ausführungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedenen Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Teil von Anweisungen darstellen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion bzw. Funktionen aufweisen. In einigen alternativen Ausführungen können die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zum Beispiel können zwei nacheinander gezeigte Blöcke in Wirklichkeit als ein Schritt erfolgen, gleichzeitig, im Wesentlichen gleichzeitig, teilweise oder vollständig zeitlich überlappend ausgeführt werden, oder die Blöcke können manchmal je nach entsprechender Funktionalität in umgekehrter Reihenfolge ausgeführt werden. Es ist ferner anzumerken, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne sowie Kombinationen aus Blöcken in den Blockschaubildern und/oder den Ablaufplänen durch spezielle auf Hardware beruhende Systeme umgesetzt werden können, die die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die hier verwendete Begrifflichkeit dient lediglich zur Beschreibung bestimmter Ausführungsformen und ist nicht als Beschränkung der verschiedenen Ausführungsformen gedacht. Im hier verwendeten Sinne sollen die Singularformen „ein/e/r,“ und „der/die/das“ auch die Pluralformen enthalten, sofern der Kontext dies nicht eindeutig anders vorgibt. Des Weiteren wird darauf verwiesen, dass die Begriffe „enthält“ und/oder „enthaltend“ in dieser Beschreibung das Vorhandensein der genannten Merkmale, Ganzzahlen, Schritte, Operationen, Elemente und/oder Komponenten angeben, ohne jedoch das Vorhandensein oder die Hinzufügung von einem/einer oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Operationen, Elementen, Komponenten und/oder Gruppen derselben auszuschließen. In der obigen ausführlichen Beschreibung von Beispiel-Ausführungsformen der verschiedenen Ausführungsformen wurde auf die beigefügten Zeichnungen verwiesen (bei denen gleichlautende Bezugsziffern für identische Elemente stehen), die einen Teil hiervon bilden und in denen zum Zwecke der Veranschaulichung spezifische Beispiel-Ausführungsformen gezeigt werden, in denen die verschiedenen Ausführungsformen realisiert werden können. Diese Ausführungsformen wurden in ausreichender Detailgenauigkeit beschrieben, um dem Fachmann die Realisierung der Ausführungsformen zu ermöglichen, wobei jedoch andere Ausführungsformen verwendet und logische, mechanische, elektrische und andere Änderungen vorgenommen werden können, ohne vom Geltungsbereich der verschiedenen Ausführungsformen abzuweichen. In der obigen Beschreibung wurden zahlreiche spezifische Einzelheiten dargelegt, um ein gründliches Verständnis der verschiedenen Ausführungsformen bereitzustellen. Allerdings können die beschriebenen Ausführungsformen auch ohne diese spezifischen Einzelheiten realisiert werden. In anderen Fällen wurden bekannte Schaltungen, Strukturen und Methoden nicht im Detail gezeigt, um die Ausführungsformen nicht unverständlich zu machen.
Wenn verschiedene Bezugsziffern eine gemeinsame Zahl gefolgt von unterschiedlichen Buchstaben (z.B. 100a, 100b, 100c) oder ein Satzzeichen gefolgt von unterschiedlichen Zahlen (z.B. 100-1, 100-2 oder 100.1, 100.2) aufweisen, kann sich eine Verwendung lediglich der Bezugsziffer ohne den Buchstaben oder die folgenden Zahlen (z.B. 100) auf die Gruppe von Elementen als Ganzes, auf einen beliebigen Teilsatz der Gruppe oder auf ein Beispielexemplar aus der Gruppe beziehen.
Des Weiteren bedeutet der Ausdruck „mindestens eines von“ bei Verwendung mit einer Liste von Elementen, dass verschiedene Kombinationen aus einem oder mehreren der aufgeführten Elemente verwendet werden können und dass von jedem Element aus der Liste womöglich nur eines notwendig ist. In anderen Worten bedeutet „mindestens eines von“, dass jede beliebige Kombination von Elementen und jede beliebige Anzahl von Elementen aus der Liste verwendet werden kann, dass jedoch nicht alle Elemente in der Liste notwendig sind. Das Element kann ein bestimmtes Objekt, ein Gegenstand oder eine Kategorie sein.
Zum Beispiel, und ohne darauf beschränkt zu sein, kann „mindestens eines von Element A, Element B oder Element C“ Element A, Element A und Element B oder Element B enthalten. Dieses Beispiel kann außerdem Element A, Element B und Element C oder Element B und Element C enthalten. Selbstverständlich können beliebige Kombinationen dieser Elemente gegeben sein. In manchen veranschaulichenden Beispielen kann „mindestens eines von“ zum Beispiel, und ohne darauf beschränkt zu sein, zwei von Element A, eines von Element B und zehn von Element C, vier von Element B und sieben von Element C oder andere geeignete Kombinationen sein.
Verschiedene Vorkommen des Worts „Ausführungsform“, die innerhalb dieser Beschreibung auftreten, beziehen sich nicht notwendigerweise auf dieselbe Ausführungsform, können dies jedoch tun. Alle hier veranschaulichten oder beschriebenen Daten und Datenstrukturen sind lediglich Beispiele, und in anderen Ausführungsformen können andere Mengen von Daten, Arten von Daten, Felder, Zahlen und Arten von Fehlern, Feldnamen, Zahlen und Arten von Zeilen, Datensätze, Einträge oder Organisationsformen von Daten verwendet werden. Zusätzlich können alle Daten mit Logik kombiniert werden, so dass eine separate Datenstruktur unter Umständen nicht notwendig ist. Die vorangegangene ausführliche Beschreibung ist somit nicht in einem beschränkenden Sinne zu verstehen.
Die Beschreibungen der verschiedenen Ausführungsformen der vorliegenden Erfindung wurden zum Zwecke der Veranschaulichung vorgelegt und sind nicht als vollständig oder auf die offenbarten Ausführungsformen beschränkt zu verstehen. Der Fachmann weiß, dass zahlreiche Modifikationen und Abwandlungen möglich sind, ohne vom inhaltlichen Umfang und gedanklichen Wesensgehalt der beschriebenen Ausführungsformen abzuweichen. Die hierin verwendete Begrifflichkeit wurde gewählt, um die Grundsätze der Ausführungsformen, die praktische Anwendung oder technische Verbesserung gegenüber marktgängigen Technologien bestmöglich zu erläutern bzw. anderen Fachleuten das Verständnis der hierin offenbarten Ausführungsformen zu ermöglichen.
Obwohl die vorliegende Erfindung mit Blick auf spezifische Ausführungsformen beschrieben wurde, ist davon auszugehen, dass Änderungen und Abwandlungen hiervon für den Fachmann offensichtlich sein werden. Aus diesem Grund sind die folgenden Ansprüche so auszulegen, dass sie alle derartigen Änderungen und Abwandlungen umfassen, die innerhalb des tatsächlichen gedanklichen Wesensgehalts und Geltungsbereich der Erfindung liegen.

Claims

Computerrealisiertes Verfahren eines Vorab-Poolings von Komponenten aus virtuellen Maschinen (VMs) vor dem Start einer Bordanwendung, wobei das computerrealisierte Verfahren aufweist: Lesen eines VM-Pool-Manifests durch einen VM-Pool-Verwalter, wobei das VM-Pool-Manifest eine anfängliche Anzahl von virtuellen Maschinen aufweist, die gestartet werden sollen; Starten einer Mehrzahl von Basis-VMs in einem VM-Pool auf Grundlage der anfänglichen Anzahl vor dem Starten einer Anwendung; Zuordnen anfänglicher Ressourcen zu einem Teil der Basis-VMs auf Grundlage einer VM-Ressourcendefinition; und Laden von Kernprogrammpaketen in den Teil der Basis-VMs.
Computerrealisiertes Verfahren nach dem vorangegangenen Anspruch, des Weiteren aufweisend: Zuweisen der Anwendung zu einer ersten Basis-VM aus dem Teil der Basis-VMs in einem Anwendungslebenszyklus-Verwalter auf Grundlage einer Anwendungsart, die sich auf die Anwendung bezieht; Starten der Anwendung in der ersten Basis-VM; und Ausführen der Anwendung.
Computerrealisiertes Verfahren nach dem vorangegangenen Anspruch, wobei ein Zuweisen der Anwendung zu der ersten Basis-VM auch auf Grundlage der anfänglichen Ressourcen erfolgt, die der ersten Basis-VM zugeordnet werden.
Computerrealisiertes Verfahren nach einem beliebigen der vorangegangenen Ansprüche und mit Merkmalen aus Anspruch 2, wobei das Starten der Anwendung aufweist: Laden einer Anwendungslogik, die sich auf die Anwendung bezieht, wobei die Anwendungslogik Injektionspunkte aufweist; Verknüpfen der Injektionspunkte mit Rezeptoren, die in der ersten Basis-VM enthalten sind; und Neuzuweisen von Ressourcen zu der ersten Basis-VM auf Grundlage einer Ressourceninformation, die sich auf die Anwendung bezieht.
Computerrealisiertes Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei die Mehrzahl von Basis-VMs mit Ausnahme des Teils der Basis-VMs in eine Wartekonfiguration versetzt werden.
Computerrealisiertes Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei ein Zuordnen der anfänglichen Ressourcen auf Grundlage eines Ressourcenzuweisungsmusters erfolgt.
Computerrealisiertes Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei die Kernprogrammpakete eine Java-Laufzeitumgebung aufweisen.
Computerrealisiertes Verfahren nach einem beliebigen der vorangegangenen Ansprüche, wobei die Anwendung eine Bordanwendung ist.
Computerprogrammprodukt für ein Vorab-Pooling von VM-Komponenten vor dem Anwendungsstart, wobei das Computerprogrammprodukt aufweist: ein oder mehrere computerlesbare Speichermedien und Programmanweisungen, die in dem einen oder den mehreren computerlesbaren Speichermedien gespeichert werden, wobei die Programmanweisungen aufweisen: Programmanweisungen zum Lesen eines VM-Pool-Manifests durch einen VM-Pool-Verwalter, wobei das VM-Pool-Manifest eine anfängliche Anzahl von virtuellen Maschinen aufweist, die gestartet werden sollen; Programmanweisungen zum Starten einer Mehrzahl von Basis-VMs in einem VM-Pool auf Grundlage der anfänglichen Anzahl vor dem Starten einer Anwendung; Programmanweisungen zum Zuordnen anfänglicher Ressourcen zu einem Teil der Basis-VMs auf Grundlage einer VM-Ressourcendefinition; und Programmanweisungen zum Laden von Kernprogrammpaketen in den Teil der Basis-VMs.
Computerprogrammprodukt nach dem vorangegangenen Anspruch, des Weiteren aufweisend: Programmanweisungen zum Zuweisen der Anwendung zu einer ersten Basis-VM aus dem Teil der Basis-VMs in einem Anwendungslebenszyklus-Verwalter auf Grundlage einer Anwendungsart, die sich auf die Anwendung bezieht; Programmanweisungen zum Starten der Anwendung in der ersten Basis-VM; und Programmanweisungen zum Ausführen der Anwendung.
Computerprogrammprodukt nach dem vorangegangenen Anspruch, wobei die Programmanweisungen zum Zuweisen der Anwendung zu der ersten Basis-VM auch die anfänglichen Ressourcen zur Grundlage haben, die der ersten Basis-VM zugeordnet werden.
Computerprogrammprodukt nach einem beliebigen der drei vorangegangenen Ansprüche und mit Merkmalen aus Anspruch 10, wobei die Programmanweisungen zum Starten der Anwendung aufweisen: Programmanweisungen zum Laden einer Anwendungslogik, die sich auf die Anwendung bezieht, wobei die Anwendungslogik Injektionspunkte aufweist; Programmanweisungen zum Verknüpfen der Injektionspunkte mit Rezeptoren, die in der Basis-VM enthalten sind; und Programmanweisungen zum Neuzuweisen von Ressourcen zu der ersten Basis-VM auf Grundlage einer Ressourceninformation, die sich auf die Anwendung bezieht.
Computerprogrammprodukt nach einem beliebigen der vier vorangegangenen Ansprüche, wobei die Basis-VMs mit Ausnahme des Teils der Basis-VMs in eine Wartekonfiguration versetzt werden.
Computerprogrammprodukt nach einem beliebigen der fünf vorangegangenen Ansprüche, wobei die Programmanweisungen zum Zuordnen der anfänglichen Ressourcen ein Ressourcenzuweisungsmuster zur Grundlage haben.
Computerprogrammprodukt nach einem beliebigen der sechs vorangegangenen Ansprüche, wobei die Kernprogrammpakete eine Java-Laufzeitumgebung aufweisen.
Computerprogrammprodukt nach einem beliebigen der sieben vorangegangenen Ansprüche, wobei die Anwendung eine Bordanwendung ist.
System für ein Vorab-Pooling von VM-Komponenten vor dem Anwendungsstart, wobei das System aufweist: einen Arbeitsspeicher; einen Prozessor; einen Speicher mit darin gespeichertem, computerausführbaren Programmcode; einen VM-Pool-Verwalter, der konfiguriert wird, um eine Mehrzahl von Basis-VMs in einem VM-Pool zu starten, wobei der VM-Pool-Verwalter des Weiteren konfiguriert wird, um anfängliche Ressourcen den Basis-VMs zuzuordnen und Kernprogrammpakete in die Basis-VMs zu laden; einen Anwendungslebenszyklus-Verwalter, der konfiguriert wird, um Anwendungen den Basis-VMs zuzuweisen; und einen Anwendungspaket-Verwalter, der konfiguriert wird, um die Anwendungen zu installieren und zu aktualisieren.
System nach dem vorangegangenen Anspruch, wobei ein Teil der Basis-VMs in eine Wartekonfiguration versetzt werden.
System nach einem beliebigen der beiden vorangegangenen Ansprüche, wobei die anfänglichen Ressourcen ein Ressourcenzuweisungsmusters zur Grundlage haben.
System nach einem beliebigen der drei vorangegangenen Ansprüche, wobei die den Basis-VMs zugeordneten Anwendungen auch die anfänglichen Ressourcen zur Grundlage haben, die den ersten Basis-VMs zugeordnet werden.