-
HINTERGRUND
-
1. Technisches Gebiet
-
Ausführungsformen der vorliegenden Erfindung betreffen Systemaktualisierungen und genauer gesagt das Ermöglichen von inkrementell durchzuführenden Systemaktualisierungen, wodurch die Zeitintervalle verkürzt oder beseitigt werden, in denen das System auf Grund Installation von Aktualisierungen nicht verfügbar ist.
-
2. Erörterung der verwandten Technik
-
Für Kunden, die große, geschäftskritische, weltweit verteilte Unternehmens-Content-Management-Systeme einsetzen, ist es schwierig, ausreichende Zeitfenster (oder Zeitintervalle) für Wartungen zum Außerbetriebsetzen des Systems auszumachen, um selbst kleine Systemaufrüstungsvorgänge durchzuführen. Dies liegt an verschiedenen Faktoren, darunter zum Beispiel an der großen Bedeutung dieser Systeme, der großen Anzahl abhängiger Benutzer (was zu hohen Kosten selbst bei kurzen Systemausfallzeiten führt) und der ununterbrochenen Aktivität, die davon herrührt, dass Benutzer über eine Vielzahl von Erdteilen verteilt sind. Dementsprechend wird die Realisierung von Systemaufrüstungen tendenziell über längere Zeit aufgeschoben.
-
KURZDARSTELLUNG
-
Gemäß einer Ausführungsform der vorliegenden Erfindung aktualisiert ein Computersystem ein System, das eine Vielzahl von Server-Instanzen beinhaltet und zumindest einen Prozessor aufweist. Das Computersystem ermittelt eine Konfigurationsstufe für jede im Betrieb befindliche Server-Instanz. Ein oder mehrere Sätze von Betriebsmerkmalen werden dem System auf der Grundlage eines Vergleichs zwischen den ermittelten Konfigurationsstufen der im Betrieb befindlichen Server-Instanzen und Mindestkonfigurationsstufen hinzugefügt, die dem einem oder den mehreren Sätzen von Betriebsmerkmalen zugehörig sind. Es werden Server-Operationen ausgeführt, und ein oder mehrere entsprechende Sätze von Betriebsmerkmalen werden auf die Server-Operationen in Reaktion auf das Hinzufügen dieser entsprechenden Sätze von Betriebsmerkmalen zu dem System angewendet. Ausführungsformen der vorliegenden Erfindung beinhalten des Weiteren ein Verfahren und ein Computerprogrammprodukt zum Aktualisieren eines Systems, darunter einer Vielzahl von Server-Instanzen, auf im Wesentlichen die oben beschriebene Weise.
-
KURZBESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNGEN
-
1 ist eine schematische Veranschaulichung einer beispielhaften Umgebung oder eines beispielhaften Systems einer Ausführungsform der vorliegenden Erfindung.
-
2 ist ein Ablaufplan, der eine Weise veranschaulicht, in der ein angefordertes Paket gemäß einer Ausführungsform der vorliegenden Erfindung installiert wird.
-
3 ist eine schematische Veranschaulichung eines beispielhaften Szenarios, in dem ein Installieren eines angeforderten Pakets gemäß einer Ausführungsform der vorliegenden Erfindung verweigert wird.
-
4 ist eine schematische Veranschaulichung eines beispielhaften Szenarios, in dem ein Installieren eines angeforderten Pakets gemäß einer Ausführungsform der vorliegenden Erfindung zugelassen wird.
-
5 ist ein Ablaufplan, der eine Weise veranschaulicht, in der eine Server-Instanz zur Verwendung mit installierten Paketen gemäß einer Ausführungsform der vorliegenden Erfindung überprüft wird.
-
6 ist eine schematische Veranschaulichung eines beispielhaften Szenarios, in dem ein Initiieren einer Server-Instanz, die mit installierten Paketen inkompatibel ist, gemäß einer Ausführungsform der vorliegenden Erfindung beendet wird.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Ausführungsformen der vorliegenden Erfindung stellen eine Weise zum inkrementellen Aktualisieren (einschließlich Aufrüsten) eines Systems bereit. Mit anderen Worten kann ein Teil des Systems außer Betrieb gesetzt werden, um aktualisiert zu werden, während verbleibende Systemteile weiterarbeiten.
-
Um inkrementelle Systemaktualisierungen bereitzustellen, werden verschiedene Server-Instanzen (z. B. Instanzen von physischen oder virtuellen Servern) in die Lage versetzt, mit verschiedenen Codeänderungsstufen zu arbeiten. Ein Hindernis dafür zuzulassen, dass mehrere Server-Instanzen auf verschiedenen Codeänderungsstufen arbeiten, besteht in der inhärenten Funktionscodeverarbeitung, die auf der Grundlage von zusätzlichen Merkmalen oder Fähigkeiten einer bestimmten Codeänderung stattfindet. Neuere Codeänderungen haben möglicherweise Kenntnis von vorherigen Metadatenelementen und -funktionen, ältere Codeänderungen haben jedoch keine Kenntnis von neuen Datenelementen und/oder -funktionen, die neueren Codeversionen innewohnen sind. Da die Server-Instanzen sämtlich auf der Grundlage derselben persistenten Datensätze arbeiten und in der Lage sein müssen, Anforderungen für ein beliebiges Objekt innerhalb des Systems zu bearbeiten, stellen Ausführungsformen der vorliegenden Erfindung eine Weise bereit, um sicherzustellen, dass neuere Server-Instanzen keine neuen Datenelemente einführen oder das Verarbeitungsverhalten für bestehende Datenelemente in einer Weise ändern, die Integritätsprobleme entweder für die alten oder die neuen Server-Instanzen verursacht.
-
Ausführungsformen der vorliegenden Erfindung legen eine strikte Durchsetzung eines Zusammenstellungsmechanismus fest und stellen diese bereit, mittels derer alle neuen Datenelemente und jegliche neuen Funktionsverhaltensweisen strikt auf eine Weise gesteuert werden, die eine einheitliche und geeignete Verarbeitung sowohl mittels alter als auch neuer Server-Instanzen garantiert. Ein Paket (das hierin zur Erläuterung als „Add-in”-Komponente bezeichnet werden kann) legt einen logisch zugehörigen Satz von Metadatenelementen und sonstigen Komponenten fest, der dem System hinzugefügt werden soll (oder mit dem eine zuvor vorhandene Komponente desselben aktualisiert werden soll) und einheitlich verwaltet werden soll.
-
Ausführungsformen der vorliegenden Erfindung formalisieren die auf Komponenten beruhende Paket- oder Add-in-Struktur, um den Funktionsmechanismus zum Steuern (oder Durchschalten) von Funktionsverhaltensweisen auf der Seite des Servers bereitzustellen. Mit anderen Worten steuert das Vorhandensein oder Fehlen dieser Add-in-Komponenten die logischen Programmcodepfade, die innerhalb des Servers ausgeführt werden. Neue Programmcodepfade werden ausschließlich auf der Grundlage des Vorhandenseins der Add-in-Komponente entworfen und realisiert, und sämtliche vorherigen Verhaltensweisen werden bei Fehlen der Add-in-Komponente beibehalten. Diese funktionale Konformität, die auf dem Vorhandensein oder Fehlen einer Add-in-Komponente beruht, wird auf der Daten-Server-Schicht und auf der Benutzeroberflächenschicht durchgesetzt. Alle Persistenz- und Funktionsvorgänge für eine bestimmte Anforderung an das System werden auf der Datenschicht gesteuert, wohingegen die gesamte Funktionalität der Benutzeroberfläche, die einem bestimmten Merkmalssatz zugehörig ist, darauf beruhend, ob dieses Merkmal aktiviert („eingeschaltet)” worden ist, auf der Benutzeroberflächenschicht gesteuert wird. Die Aktivierung ist in dem Einsatz der zugehörigen Add-in-Komponente implizit.
-
Die Pakete oder Add-in-Komponenten bedürfen vor dem Einsatz einer bestimmten Codeänderungsstufe. Jeder Einsatz eines bestimmten Pakets oder einer bestimmten Add-in-Komponente wird strikt in der Weise durchgesetzt, dass eine Add-in-Komponente nie zum Einsatz kommen darf, bis alle maßgeblichen Server-Instanzen auf die angegebene Codeänderungsstufe aktualisiert worden sind. Das Verhalten sowohl auf der Server- als auch auf der Client-Seite wird durch Ausführungsformen der vorliegenden Erfindung auf der Grundlage des Vorhandenseins oder des Fehlens einer gegebenen Add-in-Komponente gesteuert oder sonst durchgeschaltet. Der Ansatz der Ausführungsformen der vorliegenden Erfindung ermöglicht erheblich allgemeinere Ermittlungen über den Zustand sämtlicher Datenelemente, die mit einer bestimmten Add-in-Komponente in Zusammenhang stehen, und der zugehörigen Merkmale.
-
Ausführungsformen der vorliegenden Erfindung setzen verschiedene Elemente ein, darunter zum Beispiel ein Paket oder eine Add-in-Komponente und eine zugehörige Codeänderungsstufe, eine Server-Instanz-Codeänderungsstufe und eine entsprechende Registrierung, ein persistentes Repository und einen entsprechenden Datensatz von Server-Instanzen und angewendeten Add-in-Komponenten sowie Codeverhaltensweisen auf der Server-Seite auf der Grundlage von zurzeit angewendeten Add-in-Komponenten. Das Paket oder die Add-in-Komponente stellt Datendefinitionen und sonstige erforderliche Elemente dar, die ausreichen, um ein bestimmtes Merkmal oder einen bestimmten Merkmalssatz zu unterstützen. Bei einem Attribut jeder Add-in-Komponente handelt es sich um eine Server-Codeänderungs-Mindeststufe, die ausreicht, um diese Add-in-Komponente zu unterstützen. Die Anwendung einer bestimmten Add-in-Komponente wird strikt auf der Grundlage der entsprechenden Server-Codeänderungsstufen gesteuert. Ausführungsformen der vorliegenden Erfindung stellen die Garantien um diese Server-Codeänderungsstufen herum bereit, und zwar vorzugsweise in einer zustandslosen Server-Farmkonfiguration. Um diese Garantien bereitzustellen, verwaltet jede Server-Instanz (z. B. physische oder virtuelle Server-Instanzen) die Codeänderungsstufe und teilt sie mit, um das System in die Lage zu versetzen, einen Zeitpunkt zu ermitteln, an dem sich alle im Betrieb befindlichen Server-Instanzen auf einer geeigneten Codeänderungsstufe befinden, um die Anwendung einer bestimmten Add-in-Komponente zu unterstützen.
-
Eine beispielhafte Umgebung oder ein beispielhaftes System einer Ausführungsform der vorliegenden Erfindung ist in 1 veranschaulicht. Das System beinhaltet konkret eine Server-Gruppe oder Server-Farm 100 und ein oder mehrere Client- oder Endbenutzersysteme 14. Die Server-Farm beinhaltet ein oder mehrere Server-Systeme 10, die jeweils eine oder mehrere Server-Instanzen (z. B. physische und/oder virtuelle Server-Instanzen) beinhalten, die auf der physischen Hardware dieses Servers-Systems arbeiten. Beispielsweise kann ein Server-System 10 einen Hosting-Service für eine einzige Server-Instanz oder für eine Vielzahl von Server-Instanzen (z. B. für jede Server-Instanz, die durch einen virtuellen Server dargestellt wird) bereitstellen. Die Server-Systeme 10 und die Client-Systeme 14 können entfernt voneinander angeordnet sein und Daten über ein Netzwerk 12 austauschen. Das Netzwerk kann durch eine beliebige Anzahl geeigneter Datenaustauschmedien (z. B. ein Weitverkehrsnetzwerk (wide area network, WAN), eine lokales Netzwerk (local area network, LAN), das Internet, ein Intranet usw.) realisiert werden. Alternativ können sich die Server-Systeme 10 und die Client-Systeme 14 auf demselben physischen oder virtuellen Server befinden oder sich lokal beieinander befinden und Daten über ein geeignetes lokales Datenaustauschmedium (z. B. ein LAN, eine fest verdrahtete oder drahtlose Verbindung, ein Intranet usw.) austauschen.
-
Die Client-Systeme 14 ermöglichen es Benutzern, mit der Server-Farm oder -Gruppe 100 in Wechselbeziehung zu treten, um gewünschte Operationen auszuführen (z. B. Aktualisierungsanforderungen zu übermitteln usw.). Die Server-Systeme beinhalten ein Registrierungsmodul 20, ein Installationsmodul 22 und ein Überprüfungsmodul 24, um wie im Folgenden beschrieben inkrementelle Systemaktualisierungen oder -aufrüstungen zu steuern und zu verwalten. Die Server- und Client-Systeme können des Weiteren eine oder mehrere Anwendungen 26 beinhalten, um verschiedene Verarbeitungsoperationen auszuführen. Ein Datenbanksystem 18 kann verschiedene Daten für die Steuerung und Verwaltung speichern (z. B. Server-Registrierungsdaten, Codeänderungsstufen von Server-Systemen 10, Add-in-Komponenten und Codeänderungsstufen usw.). Das Datenbanksystem kann durch eine beliebige herkömmliche oder sonstige Datenbank oder Speichereinheit realisiert werden, es kann lokal bei, entfernt von oder auf denselben physischen oder virtuellen Servern wie den Server-Systemen 10 und den Client-Systemen 14 angeordnet sein und Daten über ein beliebiges geeignetes Datenaustauschmedium (z. B. ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), das Internet, eine fest verdrahte oder drahtlose Verbindung, ein Intranet usw.) austauschen.
-
Die Client-Systeme können als eine grafische Benutzeroberfläche (z. B. eine GUI usw.) oder als eine sonstige Benutzeroberfläche (z. B. Eingabeaufforderungen, Menübildschirme usw.) vorliegen, um Daten von Benutzern anzufordern, die zu den gewünschten Operationen gehören, und sie können Berichte oder Anzeigen bereitstellen, die verschiedene Daten beinhalten.
-
Die Server-Systeme 10 und die Client-Systeme 14 können durch beliebige herkömmliche oder sonstige Computersysteme realisiert werden, die vorzugsweise mit einer Anzeige oder einem Bildschirm, einer Basis (die z. B. zumindest einen Prozessor 15, einen oder mehrere Speicher 35 und/oder interne oder externe Netzwerkschnittstellen oder Datenaustauscheinheiten 25 (z. B. ein Modem, Netzwerkkarten usw.) beinhaltet), optionalen Eingabeeinheiten (z. B. einer Tastatur, einer Maus oder einer sonstige Eingabeeinheit) und einer beliebigen handelsüblichen und maßgeschneiderten Software (z. B. einer Server-/Datenaustausch-Software, einem Registrierungsmodul, einem Installationsmodul, einem Überprüfungsmodul, einer Browser-/Schnittstellen-Software, Anwendungen usw.) ausgestattet sind.
-
Das Registrierungsmodul 20, das Installationsmodul 22 und das Überprüfungsmodul 24 können ein(e) oder mehrere Module oder Einheiten beinhalten, um die verschiedenen Funktionen von Ausführungsformen der vorliegenden Erfindung auszuführen, die im Folgenden beschrieben werden. Die verschiedenen Module (z. B. das Registrierungsmodul, das Installationsmodul, das Überprüfungsmodul usw.) können durch eine beliebige Kombination einer beliebigen Anzahl von Software- und/oder Hardware-Modulen oder -Einheiten realisiert werden, und sie können sich zur Ausführung durch den Prozessor 15 innerhalb des Speichers 35 der Server-Systeme befinden.
-
Eine Weise, in der ein angefordertes Paket oder eine angeforderte Add-in-Komponente gemäß einer Ausführungsform der vorliegenden Erfindung in einer Server-Farm oder -Gruppe installiert wird (z. B. über das Registrierungsmodul 20, das Installationsmodul 22 und die entsprechenden Server-Systeme 10), wird in 2 veranschaulicht. In Schritt 200 registriert zunächst jede Server-Instanz eines Server-Systems 10 (z. B. physische und/oder virtuelle Server-Instanzen) eine entsprechende Codeänderungsstufe oder teilt sie auf andere Weise mit (z. B. über das Registrierungsmodul 20 und das entsprechende Server-System 10). Die Codeänderungsstufe und sonstige Daten, die die jeweilige Server-Instanz betreffen, werden in dem Datenbanksystem 18 gespeichert. Dieses stellt einen zentralen Speicherort bereit, um jedem im Betrieb befindlichen Server-System innerhalb einer bestimmten Implementierung zu ermöglichen, die Änderungsstufe jeder Server-Instanz zu ermitteln, wodurch ermittelt werden kann, wann eine Implementierung eine Codeänderungsstufe erreicht, die ausreicht, um die Anwendung einer gewünschten Add-in-Komponente zu unterstützen. Wenn eine Implementierung keine ausreichende Codeänderungsstufe erreicht, wird die Anwendung der Add-in-Komponente unabhängig davon verhindert, welches Server-System die Anforderung zum Anwenden dieser Komponente wie im Folgenden beschrieben empfängt.
-
Jede Server-Instanz registriert sich vorzugsweise beim Start bei einem Repository für Inhaltsdaten (oder dem Datenbanksystem 18) und stellt Daten bereit, darunter einen Status und eine Angabe zu der aktuellen Codeänderungsstufe, die dieser Server-Instanz zugehörig sind. Das Repository für Inhaltsdaten hält einen Satz von Teilsystem-Konfigurationsdaten zur jederzeitigen Aufzeichnung und Steuerung des Zustandes des Systems (oder der Servergruppe bereit, um die Paketen oder Add-in-Komponenten und Codeänderungsstufen zugehörigen Garantien bereitzustellen. Es wird ein Verriegelungsmechanismus (z. B. eine Anforderungsverriegelung) eingesetzt, der so eingestellt werden kann, dass er wie im Folgenden beschrieben Aktivitäten beschränkt, die über die Server-Gruppe oder -Farm hinweg auftreten. Dieser wird vorzugsweise als Markierung innerhalb der Teilsystem-Konfigurationsdaten (die z. B. den Status „geöffnet”/„geschlossen” der Verriegelung angibt) realisiert und steuert den Zustand des Systems und die Anwendung jeglicher Add-in-Komponenten. Die Teilsystem-Konfigurationsdaten beinhalten des Weiteren Daten für jede Server-Instanz und für jedes Paket oder jede Add-in-Komponente, das/die auf das System angewendet wird.
-
Sobald die Registrierung durchgeführt worden ist, wird in Schritt 205 auf einem Server-System 10 zum Verarbeiten eine Anforderung empfangen (z. B. über das Installationsmodul 22 und das empfangende Server-System 10), ein Paket oder eine Add-in-Komponente anzuwenden (z. B. der Server-Gruppe hinzuzufügen oder diese auf andere Weise zu aktualisieren). Der Verriegelungsmechanismus wird in Schritt 210 geladen. Wenn anfängliche Versuche fehlschlagen, den Verriegelungsmechanismus zu laden, wird das Laden mit einer bestimmten Häufigkeit wiederholt. Im Grunde wird die entsprechende Markierung innerhalb der Teilsystem-Konfigurationsdaten überprüft, um den Zustand der Verriegelung zu ermitteln. Wenn sich die Verriegelung in einem geöffneten Zustand befindet, wird die Markierung durch das Server-System gesetzt, das die Verriegelung lädt, um wie nachfolgend beschrieben das Laden der Verriegelung anzuzeigen und zu verhindern, dass Aktivitäten innerhalb des Systems (oder der Server-Gruppe) auftreten. Wenn der Verriegelungsmechanismus nicht geladen worden ist (wenn z. B. die Verriegelung durch ein weiteres Server-System geladen bleibt und nicht in einen geöffneten Zustand übergeht), wie in Schritt 215 ermittelt wird, wird die Anforderung für die Add-in-Komponente in Schritt 240 zurückgewiesen oder abgelehnt.
-
Der Verriegelungsmechanismus beseitigt im Grunde mögliche Konkurrenzsituationen und wird immer geladen, wenn eine Server-Instanz versucht, einen persistenten Zustand zu aktualisieren. Dies ermöglicht es dem System, neue Server-Instanzen daran zu hindern, zu starten oder in die Server-Farm oder -Gruppe einzutreten, nachdem hinsichtlich der Codeänderungs-Mindeststufe des Systems insgesamt und der Anwendung einer zugehörigen Add-in-Komponente eine Feststellung getroffen worden ist.
-
Wenn der Verriegelungsmechanismus geladen worden ist, wie in Schritt 215 festgestellt wird, werden in Schritt 220 die aktuellen Codeänderungsstufen für jede in Betrieb befindliche Server-Instanz aus dem Datenbanksystem 18 abgerufen und überprüft. Falls die aktuellen Codeänderungsstufen für jede in Betrieb befindliche Server-Instanz für das angeforderte Paket oder die angeforderte Add-in-Komponente ausreichen, wie in Schritt 225 festgestellt wird (wenn z. B. die Codeänderungsstufe jeder Server-Instanz höher als oder gleich wie die Codeänderungsstufe der angeforderten Add-in-Komponente ist), wird die Add-in-Komponente in Schritt 235 auf dem System installiert. Des Weiteren wird die Add-in-Komponente bei dem Repository für Inhaltsdaten (z. B. dem Datenbanksystem 18) registriert, um zu überprüfen, ob neue, startende Server-Instanzen ausreichende Codeänderungsstufen enthalten, um die angewendete Add-in-Komponente zu unterstützen, wie im Folgenden beschrieben. Demgemäß wird ein entsprechender Datensatz innerhalb der Teilsystem-Konfigurationsdaten erstellt, der die Codeänderungs-Mindeststufe angibt, die für das neu installierte Paket oder die neu installierte Add-in-Komponente erforderlich ist.
-
Falls die aktuellen Codeänderungsstufen für eine oder mehrere in Betrieb befindliche Server-Instanzen nicht für das angeforderte Paket oder die angeforderte Add-in-Komponente ausreichen, wie in Schritt 225 festgestellt wird (wenn z. B. die Codeänderungsstufen einer oder mehrerer Server-Instanzen niedriger als die Codeänderungsstufe der angeforderten Add-in-Komponente sind), wird die Anforderung für die Add-in-Komponente in Schritt 230 abgelehnt. Sobald die Anforderung verarbeitet und eine geeignete Maßnahme ergriffen worden ist (z. B. eine Ablehnung in Schritt 230 oder eine Installation der Add-in-Komponente in Schritt 235), wird der Verriegelungsmechanismus in Schritt 245 gelöst. Dies wird erreicht, indem die entsprechende Markierung in den Teilsystem-Konfigurationsdaten so gesetzt wird, dass sie angibt, dass sich die Verriegelung in einem geöffneten Zustand befindet, wodurch ein Laden durch ein nachfolgendes Server-System ermöglicht wird.
-
Ein beispielhaftes Szenario, in dem eine Anforderung für eine Anwendung eines Pakets oder einer Add-in-Komponente abgelehnt wird, wird in 3 veranschaulicht. Zunächst beinhalten die Server-Systeme 10a und 10b jeweils eine entsprechende Server-Instanz, deren Status in dem Datenbanksystem 18 gespeichert ist. Beispielsweise weist die Server-Instanz des Systems 10a eine Codeänderungsstufe 4 und einen Status „wird ausgeführt” auf, wohingegen die Server-Instanz des Server-Systems 10b eine Codeänderungsstufe 5 und einen Status „wird ausgeführt” aufweist. Das Server-System 10b empfängt eine Anforderung 300 für ein Paket oder eine Add-in-Komponente. Die Anforderung beinhaltet den Namen und die Codeänderungs-Mindeststufe für die Add-in-Komponente. In diesem beispielhaften Szenario beinhaltet die Add-in-Komponente einen Namen „Feature1” und eine Codeänderungs-Mindeststufe 5. Das Server-System 10b lädt den Verriegelungsmechanismus und fährt damit fort, die Codeänderungsstufen der in Betrieb befindlichen Server-Instanzen abzurufen und zu überprüfen, die in dem Datenbanksystem 18 gespeichert sind. Da die Server-Instanz des Server-Systems 10a eine niedrigere Codeänderungsstufe (z. B. 4) als die Codeänderungs-Mindeststufe (z. B. 5) der Add-in-Komponente beinhaltet, wird die Anforderung zurückgewiesen oder abgelehnt, und der Verriegelungsmechanismus wird gelöst.
-
Ein beispielhaftes Szenario, das eine Installation eines Pakets oder einer Add-in-Komponente ermöglicht, wird in 4 veranschaulicht. Zunächst beinhalten die Server-Systeme 10a und 10b jeweils eine entsprechende Server-Instanz, deren Status in dem Datenbanksystem 18 gespeichert ist. Beispielsweise weist die Server-Instanz des Systems 10a eine Codeänderungsstufe 5 und einen Status „wird ausgeführt” auf, während die Server-Instanz des Server-Systems 10b eine Codeänderungsstufe 5 und einen Status „wird ausgeführt” aufweist. Das Server-System 10b empfängt eine Anforderung 400 für ein Paket oder eine Add-in-Komponente. Die Anforderung beinhaltet den Namen und die Codeänderungs-Mindeststufe für die Add-in-Komponente. In diesem beispielhaften Szenario beinhaltet die Add-in-Komponente einen Namen „Feature1” und eine Codeänderungs-Mindeststufe 5. Das Server-System 10b lädt den Verriegelungsmechanismus und fährt damit fort, die Codeänderungsstufen der in Betrieb befindlichen Server-Instanzen abzurufen und zu überprüfen, die in dem Datenbanksystem 18 gespeichert sind. Da die Server-Instanzen der Server-Systeme 10a und 10b jeweils eine höhere oder gleich hohe Codeänderungsstufe (z. B. 5) als/wie die Codeänderungs-Mindeststufe (z. B. 5) der Add-in-Komponente beinhalten, wird die Add-in-Komponente in dem System installiert, und der Verriegelungsmechanismus wird gelöst. Darüber hinaus wird die installierte Add-in-Komponente registriert, wobei der entsprechende Name und die Codeänderungs-Mindeststufe für diese Komponente in dem Datenbanksystem 18 gespeichert werden.
-
Die Installation von Paketen oder Add-in-Komponenten wird so gesteuert, dass diese Komponenten in Reaktion darauf installiert werden können, dass alle in Betrieb befindlichen Server-Instanzen eines Systems die Anforderungen an die Codeänderungs-Mindeststufe erfüllen, die für die Add-in-Komponente angegeben sind. Dies ermöglicht, dass eine Reihe von Add-in-Komponenten für eine Systemaktualisierung oder -aufrüstung inkrementell (z. B. eine Komponente nach der anderen) auf ein System angewendet wird und gleichzeitig eine Kompatibilität der in Betrieb befindlichen Server-Instanzen mit den Add-in-Komponenten sichergestellt wird.
-
Die Add-in-Komponenten werden jedoch gegebenenfalls während eines Zeitintervalls angewendet, in dem eine oder mehrere Server-Instanzen des Systems nicht verfügbar sind. Beispielsweise kann eine Server-Instanz für eine Routinewartung oder für Aktualisierungen (z. B. zum Installieren einer neuen Codeänderung) außer Betrieb gesetzt sein, während verbleibende Server-Instanzen in Betrieb bleiben, um ein Außerbetriebsetzen des gesamten Systems zu vermeiden. In diesem Fall kann die Server-Instanz mit den neuen Add-in-Komponenten inkompatibel werden, die während des Zeitraums installiert worden sind, in dem die Server-Instanz nicht verfügbar war. Dementsprechend überprüfen Ausführungsformen der vorliegenden Erfindung neu verfügbare Server-Instanzen auf Kompatibilität mit installierten Add-in-Komponenten, bevor sie einen Abschluss des Startvorgangs oder ein Eintreten in eine Server-Gruppe oder -Farm ermöglichen. Dies ermöglicht es, eine oder mehrere Server-Instanzen der Verfügbarkeit zu entziehen (z. B. zur Wartung, für Aktualisierungen usw.), während der Betrieb des Systems über verbleibende verfügbare Server-Instanzen aufrechterhalten wird.
-
Eine Weise, in der eine Server-Instanz zur Verwendung mit installierten Paketen oder Add-in-Komponenten gemäß einer Ausführungsform der vorliegenden Erfindung überprüft wird (z. B. über das Überprüfungsmodul 24 und ein entsprechendes Server-System 10), wird in 5 veranschaulicht. Zunächst wird in Schritt 500 eine Server-Instanz initiiert und eine Startsequenz für die Server-Instanz eingeleitet. Der Verriegelungsmechanismus wird in Schritt 505 im Wesentlichen auf dieselbe Weise wie oben beschrieben geladen. Falls anfängliche Versuche, den Verriegelungsmechanismus zu laden, fehlschlagen, wird eine geeignete Fehlerbedingung protokolliert. Der Verriegelungsmechanismus ermöglicht es dem System, neue Server-Instanzen daran zu hindern, zu starten oder in die Server-Farm oder -Gruppe einzutreten, nachdem hinsichtlich der Codeänderungs-Mindeststufe des Systems insgesamt und der Add-in-Komponenten eine Feststellung getroffen worden ist.
-
Sobald der Verriegelungsmechanismus geladen worden ist, werden in Schritt 510 die aktuellen Codeänderungsstufen für jede installierte Add-in-Komponente aus dem Datenbanksystem 18 abgerufen und überprüft. Falls die initiierte Server-Instanz für eine oder mehrere der installierten Add-in-Komponenten eine nicht ausreichende Codeänderungsstufe aufweist, wie in Schritt 515 ermittelt wird (wenn z. B. die initiierte Server-Instanz eine niedrigere Codeänderungs-Mindeststufe als die Codeänderungs-Mindeststufe für eine oder mehrere der installierten Add-in-Komponenten aufweist), wird der Verriegelungsmechanismus in Schritt 530 im Wesentliche auf dieselbe Weise wie oben beschrieben gelöst. Darüber hinaus wird in Schritt 535 die Startsequenz beendet, und es wird eine Warnung für das System protokolliert und/oder angezeigt, die angibt, dass sich alle neuen Server-Instanzen auf der Codeänderungs-Mindeststufe befinden müssen, um zu starten und den Startvorgang zu beenden.
-
Wenn die initiierte Server-Instanz eine Codeänderungsstufe aufweist, die der Codeänderungs-Mindeststufe für jede der installierten Add-in-Komponenten genügt, wie in Schritt 515 ermittelt worden ist (wenn z. B. die initiierte Server-Instanz eine höhere oder gleich hohe Codeänderungsstufe als/wie die Codeänderungs-Mindeststufe für jede der installierten Add-in-Komponenten aufweist), wird in Schritt 520 die Startsequenz abgeschlossen, und der aktuelle Status und die Codeänderungsstufe der Server-Instanz werden in den Teilsystem-Konfigurationsdaten innerhalb des Datenbanksystems 18 aktualisiert. Der Verriegelungsmechanismus wird anschließend in Schritt 525 im Wesentlichen auf dieselbe Weise wie oben beschrieben gelöst.
-
Ein beispielhaftes Szenario, in dem eine Initiierung einer Server-Instanz, die mit installierten Paketen oder Add-in-Komponenten inkompatibel ist, gemäß einer Ausführungsform der vorliegenden Erfindung beendet wird in 6 veranschaulicht. Zunächst beinhalten die Server-Systeme 10a und 10b jeweils eine entsprechende Server-Instanz, deren Status in dem Datenbanksystem 18 gespeichert ist. Des Weiteren werden die Daten für ein installiertes Paket oder eine installierte Add-in-Komponente in dem Datenbanksystem 18 gespeichert. Beispielsweise weist die Server-Instanz des Systems 10a eine Codeänderungsstufe 5 und einen Status „wird ausgeführt” auf, die Server-Instanz des Server-Systems 10b weist eine Codeänderungsstufe 4 und einen Status „beendet” auf, und ein installiertes Paket oder eine installierte Add-in-Komponente weist einen Namen „Feature1” und eine Codeänderungs-Mindeststufe 5 auf. Das Server-System 10b beinhaltet eine Server-Instanz, die initiiert worden ist und eine Startsequenz ausführt. Das Server-System 10b lädt den Verriegelungsmechanismus und fährt damit fort, die Codeänderungsstufen der installierten Add-in-Komponenten abzurufen und zu überprüfen, die in dem Datenbanksystem 18 gespeichert sind. Da die Server-Instanz des Server-Systems 10b eine niedrigere Codeänderungsstufe (z. B. 4) als die Codeänderungs-Mindeststufe (z. B. 5) der installierten Add-in-Komponente beinhaltet, wird die Startsequenz der initiierten Server-Instanz des Server-Systems 10b beendet und der Verriegelungsmechanismus gelöst.
-
Im Sinne eines weiteren Beispiels genügt die initiierte Server-Instanz der Codeänderungs-Mindeststufe für die installierten Komponenten, wenn die Codeänderungsstufe für die initiierte Server-Instanz des Server-Systems 10b im obigen Szenario 5 lautet. Dementsprechend wird zugelassen, dass die initiierte Server-Instanz die Startsequenz abschließt und in die Server-Gruppe oder -Farm eintritt. In diesem Fall werden die Daten der Server-Instanz (z. B. der Status und die Codeänderungsstufe) in dem Datenbanksystem 18 aktualisiert.
-
Ausführungsformen der vorliegenden Erfindung stellen sicher, dass alle in Betrieb befindlichen Server-Instanzen in einer Weise gesteuert werden, die garantiert, dass Codeänderungsstufen der Server-Instanzen die Mindestanforderungen eines bestimmten Pakets oder einer bestimmten Add-in-Komponente erfüllen. Folglich weist jegliche angewendete Add-in-Komponente einen Satz von in Betrieb befindlichen Server-Instanzen mit den geeigneten Codeelementen auf, um das entsprechende Merkmal zu unterstützen. Dies garantiert, dass die systemweiten Verhaltensweisen für einen bestimmten Satz von Merkmalen und Funktionen ausreichen und gleichzeitig die inkrementelle Aktualisierung von Server-Instanzen ermöglichen.
-
Ausführungsformen der vorliegenden Erfindung können des Weiteren Programmcodeverhaltensweisen auf Seiten des Servers steuern, die von den Paketen oder Add-in-Komponenten abhängen, die angewendet worden sind. Der Programmcode ist mit oder ohne ein bestimmtes installiertes Paket oder eine bestimmte installierte Add-in-Komponente funktionsfähig. Wenn eine Add-in-Komponente vorhanden ist, wird ein bestimmter Programmcodepfad für eine bestimmte Server-Operation aktiviert und (gegebenenfalls) ausgeführt. Wenn die Add-in-Komponente nicht vorhanden ist, werden die bedingte Logik und der entsprechende Programmcodepfad für eine bestimmte Server-Operation ignoriert. Im Allgemeinen haben Pakete oder Add-in-Komponenten tendenziell einander ergänzenden Charakter und stellen eine neue Funktionalität dar. Dies stellt sich üblicherweise als neue Programmcodepfade innerhalb von Server- und/oder Client-Anwendungen dar, die, auf dem Vorhandensein dieser Add-in-Komponente beruhend, bedingt ausgeführt werden.
-
Ein bestimmtes Paket oder eine bestimmte Add-in-Komponente kann ein verändertes Verhalten gegenüber einem oder mehreren vorhandenen Programmcodepfad(en) darstellen. In diesem Fall werden die alten Programmcodepfade für Situationen beibehalten, in denen die Add-in-Komponente nicht angewendet wird, wohingegen das neue Verhalten in einem neuen Programmcodepfad dargestellt wird, der bedingt ausgeführt wird, wenn die Add-in-Komponente angewendet wird. Dieses Verhalten bedingter Logik gilt in ähnlicher Weise für Metadatenpersistenzvorgänge. Die Anwendung eines neuen Merkmals kann erfordern, dass bestimmte Änderungen in einem Metadatenschema auftreten. Dieser Prozess (z. B. synchron oder asynchron) wird zu dem Zeitpunkt initiiert, an dem das Paket oder die Add-in-Komponente auf das System angewendet wird. Diese Initiierung kann wie oben beschrieben über den Verriegelungsmechanismus innerhalb der Teilsystem-Konfigurationsdaten gesteuert werden.
-
Die Programmcodelogik kann sich innerhalb der Anwendungen 26 der Server-Systeme 10 und/oder der Client-Systeme 14 befinden. Diese Logik kann durch beliebige Programmcodeanweisungen realisiert werden, die einen Bedingungssatz (z. B. IF-, DO/FOR-Schleifen, Verzweigungen usw.) beinhalten. Beispielsweise kann die bedingte Logik mit folgenden Anweisungen eingesetzt werden.
OP1
IF (ADD-IN1)
OP2
OP3
OP4
ENDIF
OP5
wobei OP1 bis OP5 allgemeine Operationen kennzeichnen. In diesem Beispiel besteht der typische Programmcodefluss ohne die Installation einer Add-in-Komponente ADD-IN1 darin, dass OP1 und OP5 ausgeführt werden. Wenn die Add-in-Komponente ADD-IN1 installiert ist, werden die Operationen OP2 bis OP4 ausgeführt. Demnach kann die Logik unabhängig von dem Installationsstatus der Add-in-Komponente ADD-IN1 in Server-Instanzen verwendet werden. Mit anderen Worten kann das System unabhängig davon arbeiten, ob die Add-in-Komponenten installiert sind. In diesem Fall arbeiten Anwendungen in einer üblichen Weise (ohne Merkmale der installierten Add-in-Komponenten zu nutzen), wenn die Add-in-Komponenten noch nicht installiert sind, und sind in der Lage die installierten Add-in-Komponenten zu nutzen, wenn diese Komponenten installiert sind und verfügbar werden.
-
Die logischen Anweisungen werden auf der Grundlage einer aufgezeichneten Markierung ausgeführt, die das Vorhandensein oder das Nichtvorhandensein einer Add-in-Komponente angibt. Die Markierung kann in den Teilsystem-Konfigurationsdaten enthalten sein. Wenn ein Paket oder eine Add-in-Komponente installiert und bei dem Datenbanksystem 18 registriert wird, wird die Markierung so gesetzt, dass sie das Vorhandensein der Add-in-Komponente angibt. Dementsprechend wird die Markierung während der Ausführung der logischen Anweisungen aus dem Datenbanksystem 18 abgerufen, um das Vorhandensein oder das Nichtvorhandensein eines Pakets oder einer Add-in-Komponente zu ermitteln, das/die in der logischen Anweisung angegeben ist, und um den entsprechenden Programmcode-Ausführungspfad zu durchlaufen.
-
Es ist ersichtlich, dass die oben beschriebenen und in den Zeichnungen veranschaulichten Ausführungsformen lediglich einige wenige der zahlreichen Möglichkeiten darstellen, Ausführungsformen zum Verwalten inkrementell angewendeter Systemaktualisierungen zu realisieren.
-
Die Umgebung oder das System der Ausführungsformen der vorliegenden Erfindung können eine beliebige Anzahl von Computer- oder sonstigen Verarbeitungssystemen (z. B. Client- oder Endbenutzersysteme, Server-Systeme usw.) und Datenbanken oder sonstige Repositorys beinhalten, die in jeder gewünschten Weise angeordnet sein können, wobei die Ausführungsformen der vorliegenden Erfindung auf einen beliebigen gewünschten Typ einer Datenverarbeitungsumgebung (z. B. Cloud-Computing-, Client-Server-, Network-Computing-, Großrechner-Systeme, eigenständige Systeme usw.) angewendet werden können. Die Computer- oder sonstigen Verarbeitungssysteme, die durch die Ausführungsformen der vorliegenden Erfindung eingesetzt werden, können durch eine beliebige Anzahl beliebiger Personal-Computer oder sonstiger Arten von Computern oder Verarbeitungssystemen (z. B. IBM kompatible, Laptop-, PDA-, Mobileinheiten usw.) realisiert werden, und sie können ein beliebiges handelsübliches Betriebssystem und eine beliebige Kombination von handelsüblicher und maßgeschneiderter Software (z. B. Browser-Software, Datenaustausch-Software, Server-Software, ein Registrierungsmodul, ein Installationsmodul, ein Überprüfungsmodul usw.) beinhalten. Diese Systeme können beliebige Arten von Bildschirmen und Eingabeeinheiten (z. B. Tastatur, Maus, Spracherkennung usw.) beinhalten, um Daten einzugeben und/oder anzuzeigen. Darüber hinaus können die Computersysteme einen Hosting-Service für eine beliebige Anzahl beliebiger physischer oder virtueller Server oder sonstiger Maschineninstanzen bereitstellen.
-
Es versteht sich, dass die Software (z. B. das Registrierungsmodul, das Installationsmodul, das Überprüfungsmodul usw.) der Ausführungsformen der vorliegenden Erfindung in einer beliebigen gewünschten Maschinensprache realisiert werden kann und durch einen Fachmann der Computertechnik auf der Grundlage der in der Beschreibung enthaltenen und in den Zeichnungen durch Ablaufpläne veranschaulichten Funktionsbeschreibungen entwickelt werden könnte. Des Weiteren verweisen jegliche hierin enthaltene Bezugnahmen auf Software, die verschiedene Funktionen ausführt, im Allgemeinen auf Computersysteme oder Prozessoren, die diese Funktionen unter einer Software-Steuerung ausführen. Die Computersysteme der Ausführungsformen der vorliegenden Erfindung können alternativ durch jeden beliebigen Typ von Hardware und/oder sonstiger Verarbeitungsschaltungen realisiert werden.
-
Die verschiedenen Funktionen der Computer- oder sonstigen Verarbeitungssysteme können in beliebiger Weise auf eine beliebige Anzahl von Software- und/oder Hardware-Modulen oder -Einheiten, Verarbeitungs- oder Computersystemen und/oder -schaltungen verteilt werden, wobei die Computer- oder Verarbeitungssysteme lokal oder entfernt voneinander angeordnet sein können und Daten über ein beliebiges geeignetes Datenaustauschmedium (z. B. LAN, WAN, ein Intranet, das Internet, eine fest verdrahtete Verbindung, eine Modemverbindung, eine drahtlose Verbindung usw.) austauschen können. Beispielsweise können die Funktionen der Ausführungsformen der vorliegenden Erfindung in beliebiger Weise auf die verschiedenen Endbenutzer-/Client- und Server-Systeme und/oder beliebige sonstige dazwischengeschaltete Verarbeitungseinheiten verteilt werden. Die Software und/oder die Algorithmen, die oben beschrieben und in den Ablaufplänen veranschaulicht sind, können in beliebiger Weise verändert werden, die die hierin beschriebenen Funktionen erzielt. Darüber hinaus können die Funktionen in den Ablaufplänen oder der Beschreibung in beliebiger Reihenfolge ausgeführt werden, die eine gewünschte Operation bewirkt.
-
Die Software der Ausführungsformen der vorliegenden Erfindung (z. B. das Registrierungsmodul, das Installationsmodul, das Überprüfungsmodul usw.) kann auf einem beschreibbaren oder computerverwendbaren Medium (z. B. magnetischen oder optischen Medien, magnetooptischen Medien, Disketten, CD-ROM, DVD, Speichereinheiten usw.) zur Verwendung auf eigenständigen Systemen oder Systemen verfügbar sein, die durch ein Netzwerk oder ein sonstiges Datenaustauschmedium verbunden sind.
-
Das Datenaustauschnetzwerk kann durch eine beliebige Anzahl eines beliebigen Typs von Datenaustauschnetzwerk (z. B. LAN, WAN, Internet, Intranet, VPN usw.) realisiert werden. Die Computer- oder sonstigen Verarbeitungssysteme der Ausführungsformen der vorliegenden Erfindung können beliebige herkömmliche oder sonstige Datenaustauscheinheiten beinhalten, um Daten mithilfe beliebiger herkömmlicher oder sonstiger Protokolle über das Netzwerk auszutauschen. Die Computer- oder sonstigen Verarbeitungssysteme können jeden beliebigen Verbindungstyp (z. B. drahtgebunden, drahtlos usw.) für den Zugriff auf das Netzwerk verwenden. Lokale Datenaustauschmedien können durch beliebige geeignete Datenaustauschmedien (z. B. ein lokales Netzwerk (LAN), eine fest verdrahtete oder drahtlose Verknüpfung, ein Intranet usw.) realisiert werden.
-
Das System kann eine beliebige Anzahl beliebiger herkömmlicher oder sonstiger Datenbanken, Datenspeicher oder Speicherstrukturen (z. B. Dateien, Datenbanken, Datenstrukturen, Daten- oder sonstige Repositorys usw.) einsetzen, um Daten (z. B. Codeänderungsstufen, Paket- oder Add-in-Komponentendaten, Codeausführungsmarkierungen, Verriegelungsmechanismusmarkierungen usw.) für eine beliebige Anzahl von Server- oder sonstigen Instanzen (z. B. Instanzen von sonstigen Typen physischer oder virtueller Maschinen usw.) zu speichern. Das Datenbanksystem kann durch eine beliebige Anzahl beliebiger herkömmlicher oder sonstiger Datenbanken, Datenspeicher oder Speicherstrukturen (z. B. Dateien, Datenbanken, Datenstrukturen, Daten- oder sonstige Repositorys usw.) realisiert werden, um Daten (z. B. Codeänderungsstufen, Paket- oder Add-in-Komponentendaten, Codeausführungsmarkierungen, Verriegelungsmechanismusmarkierungen usw.) zu speichern. Das Datenbanksystem kann in den Server- und/oder Client-Systemen enthalten oder mit diesen verbunden sein. Die Datenbanksysteme und/oder Speicherstrukturen können entfernt von oder lokal bei den Computer- oder sonstigen Verarbeitungssystemen angeordnet sein und können beliebige gewünschte Daten (z. B. Codeänderungsstufen, Paket- oder Add-in-Komponentendaten, Codeausführungsmarkierungen, Verriegelungsmechanismusmarkierungen usw.) speichern.
-
Die Pakete oder Add-in-Komponenten können eine beliebige Anzahl beliebiger gewünschter Aktualisierungen oder Aufrüstungen für das System (z. B. Merkmale, Datensätze oder -strukturen, Prozesse usw.) beinhalten, wobei auf der Grundlage der Überprüfung eine beliebige Anzahl von Paketen oder Add-in-Komponenten angewendet werden kann. Beispielsweise können zwei oder mehr Pakete in Reaktion auf die Codeänderungsstufen der Server-Instanzen angewendet werden, die der neuesten (z. B. höchsten usw.) Codeänderungsstufe der Pakete genügen, die angewendet werden sollen. Des Weiteren können die Pakete oder Add-in-Komponenten einen beliebigen Teil oder eine vollständige Gesamtaktualisierung für das System beinhalten.
-
Die Codeänderungsstufen können durch eine beliebige Anzahl beliebiger Typen von Zeichen, Ziffern oder Symbolen (z. B. numerisch, alphanumerisch, mit Symbolen usw.) dargestellt werden, die beliebige gewünschte Werte aufweisen. Beliebige Werte können dazu verwendet werden, neue oder ältere Codeänderungen anzugeben (z. B. können höhere Werte neuere Codeänderungen angeben, niedrigere Werte können neuere Codeänderungen angeben, die Länge des Wertes kann neue Codeänderungen angeben usw.). Die Codeänderungsstufen können in beliebiger Weise verglichen werden, um eine Kompatibilität zwischen Paketen und Server-Instanzen zu ermitteln (z. B. höher als, niedriger als, gleich wie usw.). Alternativ können beliebige gewünschte Eigenschaften der Pakete und Server-Instanzen miteinander verglichen werden, um eine Kompatibilität zu ermitteln (z. B. Freigabedaten, Titel, Hinweise innerhalb des Codes usw.).
-
Die Markierungen für den Verriegelungsmechanismus und das Vorhandensein von Paketen können durch eine beliebige Anzahl von Markierungen oder sonstigen Hinweisen dargestellt werden. Die Markierungen können durch eine beliebige Anzahl beliebiger Typen von Zeichen, Ziffern oder Symbolen (z. B. numerisch, alphanumerisch, mit Symbolen usw.) dargestellt werden, die beliebige gewünschte Werte aufweisen. Es können beliebige Werte verwendet werden, um den geöffneten/geschlossenen Zustand der Verriegelung oder das Vorhandensein/Fehlen eines Pakets anzugeben (z. B. kann eine eins einen geschlossenen oder geladenen Zustand oder das Vorhandensein eines Pakets darstellen, wohingegen eine null einen geöffneten oder verfügbaren Zustand oder das Fehlen eines Pakets angeben kann, usw.). Die verschiedenen Fehlerbedingungen können protokolliert oder dem System oder Benutzer angegeben/angezeigt werden. Die Benachrichtigung kann beliebige gewünschte Daten beinhalten, die die Fehlerbedingung betreffen (z. B. eine nicht geladene Verriegelung, inkompatible Codeänderungsstufen usw.).
-
Es kann ein beliebiger geeigneter bedingter Ausdruck dazu verwendet werden, den Programmcodepfad auf der Grundlage des Vorhandenseins oder Fehlens eines Pakets zu steuern. Diese bedingten Anweisungen können innerhalb eines beliebigen gewünschten Programmcodes auf den Server-, Client- oder sonstigen Einheiten auftreten, die mit dem System verbunden sind.
-
Die Ausführungsformen der vorliegenden Erfindung können eine beliebige Anzahl eines beliebigen Typs einer Benutzeroberfläche (z. B. einer grafischen Benutzeroberfläche (Graphical User Interface, GUI), einer Befehlszeile, einer Eingabeaufforderung usw.) einsetzen, um Daten (z. B. Pakete oder Add-in-Komponenten, Codeänderungsstufen, Fehlerbenachrichtigungen usw.) zu beziehen oder bereitzustellen, wobei die Benutzeroberfläche beliebige Daten beinhalten kann, die in beliebiger Weise angeordnet sein können. Die Benutzeroberfläche kann eine beliebige Anzahl beliebiger Typen von Eingabe- oder Betätigungsmechanismen (z. B. Schaltflächen, Symbole, Felder, Kästchen, Verknüpfungen usw.), die an beliebigen Stellen angeordnet sind, zum Eingeben/Anzeigen von Daten und zum Einleiten gewünschter Vorgänge über beliebige geeignete Eingabeeinheiten (z. B. eine Maus, eine Tastatur usw.) beinhalten. Die Anzeigen der Benutzeroberfläche können beliebige geeignete Aktuatoren (z. B. Verknüpfungen, Registerkarten usw.) beinhalten, um zwischen den Anzeigen in beliebiger Weise zu navigieren.
-
Der Bericht kann beliebige Daten beinhalten, die in beliebiger Weise angeordnet sein können, und er kann auf der Grundlage von Regeln oder sonstigen Kriterien so konfigurierbar sein, dass einem Benutzer gewünschte Daten (z. B. Pakete oder Add-in-Komponenten, Codeänderungsstufen, Fehlerbenachrichtigungen usw.) bereitgestellt werden.
-
Die Ausführungsformen der vorliegenden Erfindung sind nicht auf die oben beschriebenen konkreten Aufgaben oder Algorithmen beschränkt, sondern können dazu verwendet werden, inkrementelle Systemaktualisierungen auf der Grundlage einer Kompatibilität zwischen den Systemaktualisierungen und beliebigen gewünschten Konfigurationselementen oder Eigenschaften von Objektinstanzen (z. B. von Instanzen von Maschinen, physischen oder virtuellen Instanzen, Programmen/Anwendungen, BIOS- oder Betriebssystemaktualisierungen usw.) zu ermöglichen. Alternativ können Ausführungsformen der vorliegenden Erfindung einen Betrieb von Anwendungen unabhängig von einer Kompatibilität mit installierten Aktualisierungen ermöglichen.
-
Die hierin verwendete Terminologie dient lediglich der Beschreibung bestimmter Ausführungsformen und soll die Erfindung nicht beschränken. So, wie sie hierin verwendet werden, sollen die Singularformen „ein”, „eine” und „der”, „die”, „das” auch die Pluralformen beinhalten, sofern dies aus dem Kontext nicht eindeutig anders hervorgeht. Es versteht sich darüber hinaus, dass die Begriffe „aufweist”, „aufweisend”, „beinhaltet”, „beinhaltend”, „verfügt über”, „verfügen über”, „über etw. verfügend”, „mit” und dergleichen, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, Ganzzahlen, Schritten, Vorgängen, Elementen und/oder Komponenten bezeichnen, jedoch nicht das Vorhandensein oder die Beifügung von einem/einer oder mehreren anderen Merkmalen, Ganzzahlen, Schritten, Vorgängen, Elementen, Komponenten und/oder Gruppen davon ausschließen.
-
Die entsprechenden Strukturen, Materialien, Vorgänge und Entsprechungen aller Mittel oder aus Schritt plus Funktion bestehender Elemente in den nachstehenden Ansprüchen sollen jede Struktur, jedes Material bzw. jeden Vorgang zum Ausführen der Funktion in Kombination mit anderen beanspruchten Elementen als ausdrücklich beansprucht beinhalten. Die Beschreibung der vorliegenden Erfindung erfolgte zum Zweck der Veranschaulichung und Beschreibung, ist jedoch nicht erschöpfend oder auf die Erfindung in der dargestellten Form beschränkt gemeint. Viele Modifizierungen und Varianten sind für Fachleute ersichtlich, ohne vom inhaltlichen Umfang und gedanklichen Wesensgehalt der Erfindung abzuweichen. Die Ausführungsform wurde ausgewählt und beschrieben, um die Grundgedanken der Erfindung und die praktische Anwendung bestmöglich zu erläutern und um anderen Fachleuten das Verstehen der Erfindung für verschiedene Ausführungsformen mit verschiedenen, für den in Betracht gezogenen Einsatz geeigneten Modifizierungen zu ermöglichen.
-
Wie für einen Fachmann ersichtlich ist, können Aspekte der vorliegenden Erfindung als System, Verfahren oder Computerprogrammprodukt verkörpert werden. Dementsprechend können Aspekte der vorliegenden Erfindung eine reine Hardware-Ausführungsform, eine reine Software-Ausführungsform (darunter Firmware, residente Software, Mikrocode usw.) oder eine Ausführungsform annehmen, in der Software- und Hardware-Aspekte kombiniert werden, die hierin sämtlich verallgemeinernd als „Schaltung”, „Modul” oder „System” bezeichnet werden können. Des Weiteren können Aspekte der vorliegenden Erfindung die Form eines Computerprogrammprodukts annehmen, das in einem oder mehreren computerlesbaren Medien verkörpert wird, auf denen computerlesbarer Programmcode verkörpert ist.
-
Es kann eine beliebige Kombination eines oder mehrerer computerlesbarer Medien verwendet werden. Bei dem computerlesbaren Medium kann es sich um ein computerlesbares Signalmedium oder ein computerlesbares Speichermedium handeln. Bei dem computerlesbaren Speichermedium kann es sich zum Beispiel um ein(e) elektronische(s), magnetische(s), optische(s), elektromagnetische(s), Infrarot- bzw. Halbleitersystem, Vorrichtung oder Einheit oder um eine beliebige geeignete Kombination der Vorgenannten handeln, ohne darauf beschränkt zu sein. Zu konkreteren Beispielen (einer nicht erschöpfenden Liste) des computerlesbaren Speichermediums würden folgende gehören: eine elektrische Verbindung mit einer oder mehreren Leitungen, eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (random access memory, RAM), ein Festwertspeicher (read-only memory, ROM), ein löschbarer, programmierbarer Festwertspeicher (erasable programmable read-only memory, EPROM oder Flash-Speicher), ein Lichtwellenleiter, ein tragbarer Compact-Disk-Festwertspeicher (CD-ROM), eine optische Speichereinheit, eine Magnetspeichereinheit oder eine beliebige geeignete Kombination der Vorgenannten. Im Rahmen dieses Dokuments kann ein computerlesbares Speichermedium jedes physische Medium sein, das ein Programm zur Verwendung durch ein System, eine Vorrichtung oder Einheit zur Befehlsausführung bzw. in Verbindung mit diesen enthalten oder speichern kann.
-
Ein computerlesbares Signalmedium kann ein sich ausbreitendes Datensignal, in dem computerlesbarer Programmcode verkörpert ist, zum Beispiel im Basisband oder als Teil einer Trägerwelle beinhalten. Ein solches sich ausbreitendes Signal kann eine Vielfalt von Formen annehmen, darunter eine elektromagnetische, eine optische oder eine beliebige geeignete Kombination davon, ohne darauf beschränkt zu sein. Bei einem computerlesbaren Signalmedium kann es sich um ein beliebiges computerlesbares Medium handeln, das kein computerlesbares Speichermedium ist und das ein Programm zur Verwendung durch ein System, eine Vorrichtung oder Einheit zur Befehlsausführung bzw. in Verbindung mit diesen austauschen, verbreiten oder transportieren kann.
-
Auf einem computerlesbaren Medium verkörperter Programmcode kann mithilfe eines beliebigen geeigneten Mediums übertragen werden, zum Beispiel über Funk, Kabel, Lichtwellenleiterkabel, Hochfrequenz (HF) usw. oder über eine beliebige geeignete Kombination der Vorgenannten, ohne darauf beschränkt zu sein.
-
Computerprogrammcode zum Ausführen von Vorgängen für Aspekte der vorliegenden Erfindung kann in jeder beliebigen Kombination einer oder mehrerer Programmiersprachen geschrieben werden, zum Beispiel in einer objektorientierten Programmiersprache wie etwa Java, Smalltalk, C++ oder dergleichen und in herkömmlichen verfahrensorientierten Programmiersprachen wie zum Beispiel der Programmiersprache „C” oder ähnlichen Programmiersprachen. Der Programmcode kann vollständig auf dem Computer des Benutzers, zum Teil auf dem Computer des Benutzers, als eigenständiges Software-Paket, zum Teil auf dem Computer des Benutzers und zum Teil auf einem entfernt angeordneten Computer oder vollständig auf dem entfernt angeordneten Computer oder Server ausgeführt werden. In letzterem Szenario kann der entfernt angeordnete Computer mit dem Computer des Benutzers durch jede beliebige Art von Netzwerk verbunden sein, zum Beispiel durch ein lokales Netzwerk (local area network, LAN) oder ein Weitverkehrs-Netzwerk (wide area network, WAN), oder die Verbindung kann mit einem externen Computer (zum Beispiel über das Internet mithilfe eines Internet-Dienstanbieters) hergestellt werden.
-
Aspekte der vorliegenden Erfindung werden unter Bezugnahme auf Ablaufpläne und/oder Blockschaubilder von Verfahren, Vorrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der Erfindung beschrieben. Es versteht sich, dass jeder Block der Ablaufpläne und/oder Blockschaubilder und Kombinationen von Blöcken in den Ablaufplänen und/oder Blockschaubildern durch Computerprogrammbefehle realisiert werden kann/können. Diese Computerprogrammbefehle können für einen Prozessor eines Universalcomputers, eines Spezialcomputers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, sodass die Befehle, die über den Prozessor des Computers oder einer sonstigen programmierbaren Datenverarbeitungsvorrichtung ausgeführt werden, Mittel zum Realisieren der Funktionen/Vorgänge erzeugen, die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegeben sind.
-
Diese Computerprogrammbefehle können auch in einem computerlesbaren Medium gespeichert werden, das einen Computer, eine sonstige programmierbare Datenverarbeitungsvorrichtung oder sonstige Einheiten so steuern kann, dass sie in einer bestimmten Weise funktionieren, sodass die in dem computerlesbaren Medium gespeicherten Befehle einen Gegenstand (article of manufacture) erzeugen, der Befehle beinhaltet, die die/den Funktion/Vorgang realisieren, die/der in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegeben ist.
-
Die Computerprogrammbefehle können außerdem auf einen Computer, eine sonstige programmierbare Datenverarbeitungsvorrichtung oder sonstige Einheiten geladen werden, um zu bewirken, dass eine Reihe von Schritten eines Vorgangs auf dem Computer, einer sonstigen programmierbaren Vorrichtung oder sonstigen Einheiten ausgeführt wird, um einen computer-realisierten Prozess zu erzeugen, sodass die auf dem Computer oder einer sonstigen programmierbaren Vorrichtung ausgeführten Befehle Prozesse bereitstellen, um die in dem Block oder den Blöcken der Ablaufpläne und/oder der Blockschaubilder angegebenen Funktionen/Vorgänge zu realisieren.
-
Die Ablaufpläne und Blockschaubilder in den Figuren veranschaulichen die Architektur, Funktionalität und Arbeitsweise möglicher Realisierungen von Systemen, Verfahren und Computerprogrammprodukten gemäß verschiedener Ausführungsformen der vorliegenden Erfindung. In diesem Zusammenhang kann jeder Block in den Ablaufplänen oder Blockschaubildern ein Modul, ein Segment oder einen Abschnitt eines Codes darstellen, der einen oder mehrere ausführbare Befehle zum Realisieren der angegebenen logischen Funktion(en) aufweist. Es ist außerdem zu beachten, dass bei einigen alternativen Realisierungen die in dem Block angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren angegeben auftreten können. Beispielsweise können je nach beteiligter Funktionalität zwei nacheinander dargestellte Blöcke tatsächlich im Wesentlichen gleichzeitig ausgeführt werden, oder die Blöcke können bisweilen in der umgekehrten Reihenfolge ausgeführt werden. Es ist ferner zu beachten, dass jeder Block der Blockschaubilder und/oder der Ablaufpläne und Kombinationen von Blöcken in den Blockschaubildern und/oder in den Ablaufplänen durch Spezialsysteme auf der Grundlage von Hardware, die die angegebenen Funktionen oder Vorgänge ausführen, oder durch Kombinationen von Spezial-Hardware und Computerbefehlen realisiert werden können.