DE112020004493T5

DE112020004493T5 - Zwischenspeicherfähigkeit von single-page-anwendungen

Info

Publication number: DE112020004493T5
Application number: DE112020004493.9T
Authority: DE
Inventors: Dieter Buehler; Carsten Leue; Uwe Hansmann
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2019-09-24
Filing date: 2020-09-22
Publication date: 2022-08-18
Also published as: GB2603344B; GB2603344A; US20210092199A1; WO2021059113A1; JP2022549076A; JP7477251B2; CN114402577A; GB202204020D0

Abstract

Es kann ein von einem Computer umgesetztes Verfahren zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems vorgesehen sein. Das Verfahren weist ein Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart und ein Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen auf, wenn festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde. Das Verfahren weist auch ein Zwischenspeichern eines der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem und ein Empfangen einer API-Anforderung durch das Zwischenspeichersystem auf, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.

Description

HINTERGRUND
Die Erfindung betrifft allgemein das Zwischenspeichern von Inhalten in einem Content-Delivery-Network und insbesondere ein von einem Computer umgesetztes Verfahren zum Verbessern der Zwischenspeicherfähigkeit eines Ergebnisses einer API-Anforderung eines Content-Delivery-Systems. Die Erfindung betrifft ferner ein verwandtes Zwischenspeichersystem zum Verbessern der Zwischenspeicherfähigkeit eines Ergebnisses einer API-Anforderung eines Content-Delivery-Systems und ein Computerprogrammprodukt.
Je größer die Datenmengen - insbesondere sogenannter unstrukturierter Daten - für Unternehmen jeder Größe werden, desto mehr Unternehmensdaten müssen mit Content-Management-Systemen verwaltet werden. Diese können zum Speichern allein der immer größer werdenden Zahl von Dokumenten oder auch als Werkzeug zur Erstellung von Inhalten z.B. für Webseiten dienen. Auch Suchmaschinen spielen im Enterprise-Content-Management eine immer größere Rolle, nicht nur für unstrukturierte Dokumente, sondern auch für Berichte aus Datenanalysesystemen und anderen Quellen.
Auf der anderen Seite müssen die Inhalte innerhalb des Unternehmens verteilt - und teilweise auch mit Kunden und Lieferanten geteilt - und zuverlässig und konsistent zugänglich gemacht werden. Das heißt, dass die Dokumente und sonstigen Inhalte immer in der aktuellsten Version vorliegen müssen. Dabei sollte das Verteilungsnetzwerk, das auch Zwischenspeichersysteme zwischen der Quelle und dem Ziel (häufig dem Client-System unter Verwendung eines Browsers) umfassen kann, die geringstmögliche Last tragen, d.h. den geringstmöglichen Netzwerkverkehr.
Heutzutage werden clientseitig häufig Single-Page-Applications (SPAs) eingesetzt, deren Hauptmerkmal darin besteht, mit dynamischen Inhalten zu arbeiten. Solche Inhalte können als Teil einer Webseite aktualisiert werden, sobald neue Informationen verfügbar werden. Dadurch bleiben andere Inhaltselemente der Webseite statisch und müssen nicht regelmäßig aktualisiert werden.
Das Zwischenspeichern ist sehr wichtig, um eine leistungsstarke Client-Anwendung zu erreichen und gleichzeitig die Anzahl der Anforderungen (und damit die Last) an den Back-End-Server auf einem akzeptablen Niveau zu halten. Statische unveränderliche Ressourcen (wie Bilder) lassen sich einfach zwischenspeichern, indem entsprechende HTTP-Cache-Control-Header hinzugefügt werden.
Auf der anderen Seite ist das Zwischenspeichern von Antworten der REST-API (REpresentational State Transfer Application Programming Interface) viel schwieriger, da die Ergebnisse in der Regel dynamisch sind und ein Zwischenspeichern dieser Ergebnisse auf Grundlage einer Ablaufzeit möglicherweise zu veralteten Daten für die Dauer dieser Ablaufzeit führt. Um diese Einschränkung zu überwinden, verwenden viele Cloud-Dienste heute validierungsgestütztes Zwischenspeichern, indem sie das HTTP-„ETag“- und -„if-notmatch“-Feld verwenden. Dieser Ansatz ermöglicht es gängigen Servern (oder Zwischenspeichersystemen), zu überprüfen, ob ein Zwischenspeicher von Objekten veraltet ist, oder eine entsprechende HTTP-Anforderung an den Ursprung des Dienstes zu senden. Dieser Ansatz vermeidet die wiederholte Übertragung derselben Daten von der Quelle zum Edge-Server. Nichtsdestotrotz führt dieser Ansatz aber immer noch zu Validierungsanforderungen an den Quellserver, was diesen Server und das Netzwerk normalerweise stark belastet. Darüber hinaus ist die Validierung selbst oft alles andere als trivial, beispielsweise kann das Ergebnis eines API-Suchaufrufs von einer Vielfalt von Metadaten abhängen, die zum Filtern von der jeweiligen Suchanfrage verwendet werden.
Validierungsgestütztes Zwischenspeichern ist bei HTTP-Zwischenspeichern normalerweise schwierig. Es gibt derzeit keine technischen Mittel, um einen Browser-Zwischenspeicher zu invalidieren. Einige CDN-Zwischenspeicher (Content-Delivery-Network-Zwischenspeicher) unterstützen Invalidierung, aber Invalidierungen von CDN-Zwischenspeichern sind keine einfachen Operationen und es dauert üblicherweise lange, bis sie an alle Edge-Server (d.h. Client-Systeme) verteilt wurden. Darüber hinaus ist diese normalerweise nicht dazu gedacht, auf einer feinkörnigen Ebene, wie z.B. für einzelne parametrisierte API-Aufrufe, verwendet zu werden.
Es gibt mehrere Offenbarungen in Bezug auf Verfahren zum Verwalten von Inhalten in einem Content-Delivery-System: Das Dokument US 2017/0046438 A1 offenbart ein Suchsystem, das einen Abfrageempfänger, ein Live-Scraping-System und einen Cache-Manager umfasst. Der Abfrageempfänger ist so konfiguriert, dass er eine erste Abfrage empfängt, die zu einem ersten Anwendungszustand einer ersten Anwendung gehört. Die erste Abfrage wird von einer Benutzereinheit angefordert. Der Cache-Manager ist so konfiguriert, dass er Informationen auf Grundlage des extrahierten Inhalts speichert und als Reaktion darauf, dass der Abfrageempfänger eine zweite Abfrage empfängt, die mit der ersten Abfrage übereinstimmt, die gespeicherten Informationen selektiv der Benutzereinheit zur Anzeige für einen Benutzer bereitstellt.
Das Dokument US 2014/0372515 A1 offenbart ein Client-gestütztes Computersystem, das geeignet ist, mit einem fernen Server über ein Netzwerk Daten auszutauschen und Zugriff auf Inhalte oder Dienste bereitzustellen, die von dem Server bereitgestellt werden, wobei das System eine Speichereinheit und einen Zwischenspeicher umfasst. Der Zwischenspeicher ist geeignet, über das Netzwerk mit dem Server Daten auszutauschen, eine Anforderung vom Client an den Server abzufangen und Antworten vom Server auf einer Speichereinheit zu speichern. Der Zwischenspeicher ist ferner geeignet, automatisch zu bestimmen, wann die Anforderung über das Netzwerk an den Server gesendet werden soll.
Ein Nachteil bekannter Lösungen ist nach wie vor ein relativ hoher Netzwerkverkehr zwischen den unterschiedlichen beteiligten Systemen, d.h. dem einen oder den mehreren Content-Servern, dem einen oder den mehreren Zwischenspeichersystemen und dem einen oder den mehreren Client-Systemen. Dies gilt insbesondere für Fälle, in denen Single-Page-Applications den Zugriff auf sich dynamisch ändernde Inhalte ermöglichen.
Daher kann es notwendig sein, unbefriedigende Zustände, das heißt unnötigen Overhead-Netzwerkverkehr in einem Content-Delivery-Network, zu überwinden und dennoch einen zuverlässigen Zugriff auf die neuesten Versionen von Inhaltselementen unter Verwendung von Webseiten bereitzustellen, die einen Zugriff auf sich dynamisch ändernde Inhalte ermöglichen.
KURZDARSTELLUNG
Gemäß einem Aspekt der vorliegenden Erfindung kann ein von einem Computer umgesetztes Verfahren zum Verbessern der Zwischenspeicherfähigkeit eines Ergebnisses einer API-Anforderung eines Content-Delivery-Systems vorgesehen sein. Das Verfahren kann ein Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart sowie ein Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen aufweisen, wenn festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde.
Weiter kann das Verfahren ein Zwischenspeichern eines der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem und ein Empfangen einer API-Anforderung von dem Zwischenspeichersystem aufweisen, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.
Gemäß einem weiteren Aspekt der vorliegenden Erfindung kann ein Zwischenspeichersystem zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems vorgesehen sein. Das System kann Mittel zum Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart, Mittel zum Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen, wenn festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde, Mittel zum Zwischenspeichern eines der Inhalte der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem, und Mittel zum Empfangen einer API-Anforderung von dem Zwischenspeichersystem aufweisen, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.
Das vorgeschlagene von einem Computer umgesetzte Verfahren zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems kann mehrere Vorteile, technische Wirkungen, Beiträge und/oder Verbesserungen bieten:
Der Netzwerkverkehr zwischen dem Client und dem Content-Management-System, das üblicherweise als Back-End-Server in einem Rechenzentrum umgesetzt ist, kann erheblich verringert werden, was zu einer wirtschaftlicheren Nutzung der verfügbaren Ressourcen führt. Das Zwischenspeichersystem, das üblicherweise in einem Datenübertragungsnetzwerk zwischen dem Content-Server-System bzw. Content-Management-System im Back-End und einer Informationsnutzungseinheit wie einem Client-System umgesetzt ist, das üblicherweise mit einem Browser zum Wiedergeben der Informationen ausgestattet ist, darf keine unnötigen und unkontrollierten Anforderungen an das Back-End-System senden, sondern kann die Fähigkeit haben, die in dem - z.B. verteilten - Zwischenspeichersystem zwischengespeicherten Inhaltselemente so aktuell wie möglich zu halten. Dafür kann ein intelligentes Datenübertragungsprotokoll zwischen dem Client und dem Zwischenspeichersystem Mittel zum Steuern der Aktualität eines Inhaltselements im Client-System bereitstellen.
Das Zwischenspeichersystem muss das Inhaltselement, insbesondere eine aktualisierte Version des Inhaltselements, nur dann vom Content-Management-System anfordern, wenn festgestellt wurde, dass das im Zwischenspeichersystem zwischengespeicherte Inhaltselement veraltet ist. Dies kann in Umgebungen besonders vorteilhaft sein, in denen Single-Page-Applications verwendet werden können, die sowohl statische als auch sich dynamisch ändernde Inhalte auf derselben Webseite (oder Webanwendung) aufweisen.
Die Granularität und Kontrolle über Inhaltselemente und ihre Aktualität können konfiguriert werden, indem Gruppen von Inhaltselementen definiert werden. Auf diese Weise kann abhängig von der verfügbaren Bandbreite des Netzwerks zwischen dem Back-End-System, dem Zwischenspeichersystem sowie der Netzwerkkapazität zwischen dem Zwischenspeichersystem und dem Client eine feinkörnige oder grobkörnige Zwischenspeicher-Verwaltungsstrategie verfolgt werden. Diese Konfigurierbarkeit kann auch dazu beitragen, dass vorhandene Ressourcen auf wirtschaftlichere Weise genutzt werden können.
Der hier vorgeschlagene neue Zwischenspeicheransatz, der den neuartigen Zwischenspeicher-Seed-Parameter verwendet, kann es ermöglichen, API-Antworten unendlich lange zwischenzuspeichern. Um dies zu erreichen, verfolgen Cloud-Dienste in diesem Zusammenhang die aktuellen Zwischenspeicher-Seed-Werte je Art der Artefakte (d.h. Inhaltselemente), die von den Diensten zugänglich gemacht werden (z.B. einen Zwischenspeicher-Seed für Inhalte und einen anderen Zwischenspeicher-Seed für Datenbestände). Immer wenn eine Instanz dieser Art erstellt, geändert oder gelöscht wird, kann der entsprechende Zwischenspeicher-Seed-Wert auf einen neuen eindeutigen Wert (der noch nie zuvor verwendet wurde) aktualisiert werden. Clients können den aktuellen Seed-Wert für eine bestimmte Art über eine entsprechende REST-API abrufen.
Darüber hinaus kann dieser Ansatz es Benutzern ermöglichen, zu entscheiden, wie aktuell die geladenen Informationen auf der Client-Seite sein müssen. Die Informationen sind so aktuell wie der geladene Zwischenspeicher-Seed-Wert. Das heißt, dass wenn es für den Client ausreicht, dass Daten eine Minute veraltet sind, das Client-System die Seed-Werte jede Minute neu laden würde. In Phasen, in denen es keine Aktualisierungen der vom Cloud-Dienst (d.h. Content-Management-System) bereitgestellten Live-Daten gibt, müssen sich die Seed-Werte bei einem nachfolgenden API-Aufruf nicht ändern und werden dennoch vollständig aus dem CDN-Zwischenspeicher, d.h. dem Zwischenspeicherserver, bereitgestellt. Dieser Ansatz kann besonders für Webseiten vorteilhaft sein, die zu bestimmten Zeiten, aber nicht unbedingt nach einem zuverlässigen, stabilen Zeitplan aktualisiert werden. Dies kann einen typischen Fall für Webseiten darstellen. Nach einem Update sehen alle Client-Systeme die aktuellen Daten nach spätestens einer Minute, wogegen während des langen Zeitraums ohne Änderung alle Antworten vom Zwischenspeichersystem des CDN bereitgestellt werden. Einem Client steht es immer frei, die aktuellsten Daten zu laden, indem er entweder den Zwischenspeicher-Seed-Parameter weglässt oder ihn neu lädt.
Darüber hinaus kann die Belastung des Back-End-Servers (d.h. des CMS) aufgrund der häufigen Vermeidung der Aktualisierungsprüfung von der mittleren CDN-Schicht, d.h. den Zwischenspeicherservern, erheblich verringert werden. Dies kann zu einer besseren Reaktionszeit für regelmäßige Anforderungen an die Back-End-Server und zu geringeren Anforderungen an die Rechenleistung (d.h. zu potenziell kleineren, billigeren Servern)führen.
Im Folgenden werden weitere Ausführungsformen des erfinderischen Konzepts - anwendbar sowohl auf das System als auch auf das Verfahren - beschrieben.
Gemäß einer vorteilhaften Ausführungsform kann das Verfahren auch aufweisen: beim Feststellen - insbesondere nach Erhalt der API-Anforderung - eines Unterschieds zwischen dem zugehörigen Seed-Wert und dem ausgewählten Seed-Wert am Zwischenspeichersystem, Anfordern eines aktualisierten entsprechenden Inhaltselements als API-Anforderungsergebnis, insbesondere von dem Content-Management-System. Wenn die Seed-Werte der Anforderung und des Inhaltselements im Zwischenspeichersystem gleich sind, gibt das Zwischenspeichersystem einfach einen Seed-Wert zurück, der im Zwischenspeichersystem gespeichert ist. Darüber hinaus wird jedoch nichts ausgeführt, da der Seed-Wert unverändert (d.h. auf dem Client und dem Zwischenspeichersystem gleich) ist, insbesondere darf keine Anforderung an das Back-End-System gesendet werden.
Gemäß einer weiteren vorteilhaften Ausführungsform kann das Verfahren auch ein regelmäßiges Empfangen einer API-Anforderung für das Inhaltselement der Gruppe am Zwischenspeichersystem aufweisen. Dies kann erfolgen, um den Inhalt einer SPA in einem Browser eines Clients regelmäßig zu aktualisieren. Regelmäßig kann „in regelmäßigen Zeitabständen“ bedeuten oder durch andere Ereignisse ausgelöst werden, die vom Client-System des Browsers empfangen werden. Beispielsweise können Mitteilungen in unvorhersehbaren Zeitintervallen empfangen werden, die zum Kontext des Inhaltselements gehören; dann kann der Client/Browser automatisch eine Anforderung an das Zwischenspeichersystem senden, um ein aktualisiertes Inhaltselement zu erhalten - vorausgesetzt, der Seed-Wert unterscheidet sich. Dies kann für dynamische Webseiten von besonderem Wert sein.
Gemäß einer nützlichen Ausführungsform des Verfahrens kann die API-Anforderung als API-Anforderungsergebnis Inhalte von Elementen anfordern, die zu unterschiedlichen Gruppen von Inhaltselementarten gehören. Somit kann der oben beschriebene Mechanismus auch auf Inhaltselemente unterschiedlicher Gruppen angewendet werden. Dies kann auch von besonderem Wert für dynamische Webseiten sein, die unterschiedliche Arten von Inhaltselementen handhaben. Somit kann eine Gruppe alle Inhaltselemente einer Inhaltsart aller der Inhaltselemente des CMS wiedergeben, was bedeutet, dass sich alle Inhaltselemente einer Art in einer Gruppe befinden. In diesem Fall muss die Gruppe nicht mehr erforderlich sein; es kann nur die Art berücksichtigt werden.
Gemäß einer zulässigen Ausführungsform des Verfahrens kann der Parameter der API-Anforderung das Ergebnis einer XOR-Funktion sein, die die Seed-Werte der verschiedenen Arten als Eingabe hat. Dies kann eine direkte Art und Weise darstellen, den Netzwerkverkehr niedrig zu halten, da die Seed-Werte von mehr als einem Seed-Wert für unterschiedliche Inhaltselementarten zusammengeführt werden können. Wenn sich also zwei Seed-Werte für unterschiedliche Inhaltselementarten geändert haben oder vom Client angefordert werden, könnten die bekannten Seed-Werte durch die auf die beiden Seed-Werte angewendete XOR-Funktion zusammengeführt werden.
Gemäß einer fortgeschrittenen Ausführungsform kann das Verfahren auch ein Verwenden - am Zwischenspeichersystem - eines Zeitwertes, der größer oder gleich einem vordefinierten Zwischenspeicher-Ablaufschwellenwert ist, als Zwischenspeicher-Ablaufzeit für ein Inhaltselement eines API-Anforderungsergebnisses aufweisen. Dieser Zeitwert kann nahe am technisch möglichen Maximalwert (z.B. dem größten ganzzahligen Wert) liegen oder diesem entsprechen. Auf diese Weise kann das Inhaltselement auf dem Zwischenspeichersystem zwischengespeichert werden, bis es tatsächlich veraltet ist. Es dürfen keine versehentlichen Aktualisierungen aufgrund von Anforderungen für das Inhaltselement aufgrund von Browser/Client-Anforderungen ausgelöst werden.
Gemäß einer weiteren optionalen Ausführungsform kann das Verfahren ein Senden - insbesondere vom Zwischenspeichersystem an den Client - eines Zeitwertes als Zwischenspeicher-Ablaufzeit für ein Inhaltselement aufweisen, der größer oder gleich einem vordefinierten Zwischenspeicher-Ablaufschwellenwert ist, der z.B. nahe am technisch möglichen Maximalwert liegt oder diesem entspricht. Damit geht der Client/Browser davon aus, dass die Gültigkeitsdauer des Inhaltselements mehr oder weniger unbegrenzt ist, bis ein Unterschied der Seed-Werte im Zwischenspeichersystem festgestellt wurde.
Gemäß einer weiteren verbesserten Ausführungsform kann das Verfahren auch ein Senden - insbesondere von dem CMS-Server an den Client unter Umgehung des Zwischenspeicherservers - unter Verwendung von Push-Technologien - z.B. Web-Sockets - einer Nachricht aufweisen, die eine Aktualisierung eines Seed-Wertes in Bezug auf eines der Inhaltselemente einer Gruppe anzeigt. Aufgrund der Mechanismen der Push-Technologie kann der Client die Nachricht erhalten und feststellen, dass der Seed-Wert abgelaufen sein kann. Nun kann der Client eine aktualisierte Version des Inhaltselements vom Zwischenspeichersystem zusammen mit dem neu empfangenen zugehörigen Seed-Wert anfordern. Das Zwischenspeichersystem kann feststellen, dass die Seed-Werte des zwischengespeicherten Inhaltselements und desjenigen sich unterscheiden, das mit der API-Anforderung empfangen wurde. Auf dieser Grundlage kann das Zwischenspeichersystem das aktualisierte Inhaltselement mit dem neuen Seed-Wert von dem Content-Management-Server anfordern.
Gemäß einer praktischen Ausführungsform des Verfahrens kann das Inhaltselement ein Element einer SPA oder ein anderweitig dynamisch erzeugter Inhalt sein. In diesem Zusammenhang kann das hier vorgeschlagene Konzept seine ganze Bandbreite an Vorteilen entfalten.
Gemäß einer weiteren praktischen Ausführungsform des Verfahrens kann das API-Anforderungsergebnis ein Ergebnis einer Suchanfrage sein. Dies kann einen häufigen Anwendungsfall für das vorgeschlagene Konzept darstellen. Das Inhaltselement kann jedoch auch von einem Streaming-Analytics- oder einem Business-Intelligence- und Reporting-System übermittelt und verwaltet werden.
Gemäß einer integralen Ausführungsform kann das Verfahren vor dem Zwischenspeichern eines der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem auch ein Empfangen der API-Anforderung am Zwischenspeichersystem - insbesondere vom Client - und ein Anfordern des API-Anforderungsergebnisses, insbesondere vom CMS, aufweisen. Auf diese Weise kann der Kreis geschlossen werden und veraltete Inhaltselemente müssen niemals an den Client übermittelt und von ihm verwendet werden.
Gemäß einer weiteren verbesserten Ausführungsform des Verfahrens können alle Seed-Werte von Inhaltsarten anforderbar sein, insbesondere von dem Zwischenspeichersystem oder dem CMS oder einem unabhängigen Hilfssystem, das Seed-Werte z.B. für eine Mehrzahl von Inhaltselementen unterschiedlicher CMS oder Suchsysteme handhabt.
Darüber hinaus können Ausführungsformen die Form eines verwandten Computerprogrammprodukts annehmen, auf das von einem von einem Computer verwendbaren oder von einem Computer lesbaren Medium zugegriffen werden kann, das Programmcode zur Verwendung durch einen Computer oder ein beliebiges Anweisungsausführungssystem oder in Verbindung mit diesen bereitstellt. Im Sinne dieser Beschreibung kann ein von einem Computer verwendbares oder von einem Computer lesbares Medium aus jeder Einheit bestehen, die Mittel zum Speichern, Übertragen, Verbreiten oder Transportieren des Programms zur Verwendung durch das System, die Vorrichtung oder Einheit zum Ausführen der Anweisungen oder im Zusammenhang mit diesen umfassen kann.
KURZBESCHREIBUNG DER VERSCHIEDENEN ANSICHTEN DER ZEICHNUNGEN
Es sei darauf hingewiesen, dass Ausführungsformen der Erfindung unter Bezugnahme auf verschiedene Gegenstände beschrieben werden. Insbesondere werden einige Ausführungsformen unter Bezugnahme auf Verfahrensansprüche beschrieben, während weitere Ausführungsformen unter Bezugnahme auf Vorrichtungsansprüche beschrieben werden. Fachleute werden jedoch dem obigen und der nachfolgenden Beschreibung entnehmen, dass, sofern nicht anders angegeben, neben jeder Kombination von Merkmalen, die zu einer Art von Gegenständen gehören, auch jede Kombination von Merkmalen im Zusammenhang mit unterschiedlichen Gegenständen, insbesondere von Merkmalen der Verfahrensansprüche und Merkmalen der Vorrichtungsansprüche, als innerhalb dieses Dokuments offenbart angesehen wird.
Die oben definierten Aspekte und weitere Aspekte der vorliegenden Erfindung gehen aus den nachfolgend zu beschreibenden Ausführungsbeispielen hervor und werden anhand der Ausführungsbeispiele beschrieben, auf die die Erfindung jedoch nicht beschränkt ist.
Bevorzugte Ausführungsformen der Erfindung werden lediglich beispielhaft und unter Bezugnahme auf die folgenden Zeichnungen beschrieben:

1 zeigt ein Blockschema einer Ausführungsform des erfindungsgemäßen von einem Computer umgesetzten Verfahrens zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems.
2 zeigt ein Blockschema einer Ausführungsform mit zwei CMSs in unterschiedlichen Rechenzentren, einem Zwischenspeichersystem und Clients.
3 zeigt ein Blockschema einer Ausführungsform eines Datenflusses von einem CDN zu einem Inhaltsdienst, der von einem Zwischenspeicher-Seed-Dienst unterstützt wird.
4 zeigt ein Blockschema einer Ausführungsform des erfindungsgemäßen Zwischenspeichersystems zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems.
5 zeigt eine Ausführungsform eines Computersystems, das das Zwischenspeichersystem gemäß 4 aufweist.

DETAILLIERTE BESCHREIBUNG
Im Zusammenhang mit dieser Beschreibung können die folgenden Konventionen, Begriffe und/oder Ausdrücke verwendet werden:
Der Begriff „Zwischenspeicherfähigkeit“ kann die Eigenschaft bezeichnen, ein Inhaltselement auf effizientere Weise als in den Ursprungssystemen zwischenzuspeichern; d.h. er kann die Fähigkeit eines Systems wiedergeben, Daten - insbesondere Daten für Webseiten und noch spezieller für Single-Page-Applications - so zu speichern, dass sie schneller zugänglich gemacht werden können. Das System und der Fokus im Kontext dieses Dokuments ist ein Zwischenspeichersystem, das es ermöglichen kann, den Netzwerkverkehr von einem Client-System zu einem Inhaltsspeichersystem im Back-End zu verringern (und dadurch auch die Last auf den Back-End-Server zu verringern). Das Zwischenspeichersystem muss ein bestimmtes Inhaltselement von dem Back-End-Inhaltsspeichersystem - z.B. einem Content-Management-System - für eine Bereitstellung an ein Client-System nur dann anfordern, wenn klar ist, dass das derzeit auf dem Zwischenspeichersystem gespeicherte, d.h. zwischengespeicherte, Inhaltselement veraltet ist.
Der Begriff „API-Anforderungsergebnis“ kann eine Systemantwort als Antwort auf einen Funktionsaufruf an eine Anwendungsprogrammierschnittstelle (API) bezeichnen.
Der Begriff „Content-Delivery-System“ kann jedes verteilte Einzelkernsystem bezeichnen, das Inhaltselemente jeglicher Art speichert. Dies kann ein Content-Management-System, ein Transaktionssystem oder eine Kombination der beiden sein.
Der Begriff „eindeutiger Seed-Wert“ kann einen numerischen Wert bezeichnen, der für eine bestimmte Klasse oder Gruppe von Inhaltselementen eindeutig ist. Anstelle des numerischen Wertes können auch alphanumerische Werte oder beliebige andere digitale Strukturen verwendet werden. Ein Beispiel für den eindeutigen Seed-Wert - oder einfach Seed-Wert - kann aus einer Versionsnummer eines einzelnen Inhaltselements bestehen. Das hier vorgeschlagene Konzept stützt sich jedoch auf Gruppen von Inhaltselementen, so dass der eindeutige Seed-Wert geändert werden kann, wenn eines der Inhaltselemente in der Gruppe geändert worden sein kann. Die Gruppe kann alle Inhaltselemente einer bestimmten Art in einem Content-Management-System (oder einem Zusammenschluss von mehreren Content-Management-Systemen) aufweisen, oder sie kann aus einer Teilgruppe von Inhaltselementen einer bestimmten Art oder sogar um eine Gruppe von Inhaltselementen unterschiedlicher Art bestehen, die nach einem Thema organisiert sind.
Der Begriff „Inhaltsart“ kann eine Datenart eines Inhaltselements bezeichnen. Übliche Inhaltsarten umfassen Text, Bild, Ton, Video und Kombinationen davon, sind aber nicht darauf beschränkt. Es können jedoch beliebige strukturierte, halbstrukturierte und sogenannte unstrukturierte Daten verwendet werden. Insbesondere kann eine Gruppe alle Inhaltselemente einer Inhaltsart umfassen.
Der Begriff „Zwischenspeichern“ kann eine Zwischenspeicherung von Daten zum Gewährleisten einer schnellen Verfügbarkeit bezeichnen. Die Speicherung der Daten kann üblicherweise näher an einer Datensenke ausgeführt werden.
Der Begriff „API-Anforderung“ kann einen Funktionsaufruf bezeichnen, der eine Anwendungsprogrammierschnittstelle adressiert, um eine Antwort auszulösen. Üblicherweise ist die Antwort ein Datensatz. Eine API-Anforderung weist üblicherweise einen oder mehrere Parameter auf, die den zurückerhaltenen Datensatz angeben.
Der Begriff „Parameter“ kann hier einen Parameter im Sinne eines Funktionsaufrufs bezeichnen, d.h. eine Variable als Teil einer API-Anforderung. Ein bestimmter Parameter kann ein Seed-Wert eines Inhaltselements sein, das z.B. in einem Browser eines Client-Systems angezeigt wird, der eine bestimmte Version des derzeit verfügbaren oder geteilten Inhaltselements wiedergibt, das im/für das Client-System neu angefordert wird.
Der Begriff „XOR-Funktion“ kann eine Bitoperation bezeichnen, die nur dann einen wahren Ausgang liefert, wenn eines der Eingangsbits logisch „1“ und das andere Eingangsbit logisch „0“ ist; XOR steht für „ausschließliches Oder“. Die XOR-Funktion kann auch auf längere Bitfolgen (z.B. ein Byte) angewendet werden, wobei die Funktion in diesem Fall üblicherweise bitweise durchgeführt wird. Alternativ kann eine Hash-Funktion verwendet werden.
Der Begriff „Zwischenspeicher-Ablaufschwellenwert“ kann einen numerischen Wert bezeichnen - auch als Zeitstempel umsetzbar - nach dem ein zwischengespeichertes Inhaltselement abgelaufen sein kann, d.h. nicht mehr aktuell bzw. veraltet ist.
Der Begriff „Single-Page-Application“ (SPA) kann eine Webanwendung bzw. Website bezeichnen, die mit einem Benutzer interagiert, indem sie dynamisch eine Teilmenge einer Webseite neu schreibt, anstatt die gesamte neue Webseite von einem Server zu laden, wenn nur ein kleiner Teil aktualisiert wurde. Dieser Ansatz kann eine Unterbrechung der Benutzererfahrung zwischen aufeinanderfolgenden Seiten (oder Teilen der Seiten) vermeiden, wodurch sich die Anwendung eher wie eine Desktop-Anwendung verhält. In einer SPA wird der notwendige Code - z.B. HTML, JavaScript und CSS (Cascading Style Sheets) - beim Laden einer einzelnen Seite abgerufen, oder die entsprechenden Ressourcen, d.h. Inhaltselemente, werden dynamisch geladen und der Seite nach Bedarf hinzugefügt, üblicherweise als Reaktion auf eine Benutzeraktion. Dabei wird die Seite zu keinem Zeitpunkt neu geladen und die Steuerung nicht auf eine andere Seite übertragen. Eine Interaktion eines Benutzers mit dieser Single-Page-Application kann häufig hinter den Kulissen einen dynamischen Datenaustausch mit dem Webserver umfassen.
Der Begriff „mittlere Schicht“ kann ein geschichtetes System zwischen einem Back-End-Content-Management-System und einem Client-System bezeichnen, d.h. im Kontext dieses Dokuments das Zwischenspeichersystem.
Der Begriff „3-Ebenen-Content-Delivery-System“ kann eine Architektur zum Bereitstellen von Inhaltselementen von einem Content-Storage-System zu einem Client über eine mittlere Schicht von Netzwerken und Zwischenspeichersystemen bezeichnen.
Der Begriff „Content-Management-System“ (CMS) kann eine Kombination aus einem Hardwaresystem und Softwarekomponenten bezeichnen, die es diesem ermöglichen, die Erstellung und Änderung digitaler Inhalte, d.h. Inhaltselemente, zu verwalten. Diese Systeme unterstützen in der Regel mehrere Benutzer in einer kollaborativen Umgebung, die eine Dokumentenverwaltung mit unterschiedlichen Regelungsstilen und Arbeitsabläufen ermöglicht. Im Zusammenhang mit diesem Dokument werden Inhaltselemente in der Regel von dem CMS verwaltet, das für Single-Page-Applications dediziert sein kann. Ein weiteres Merkmal des CMS ist eine Trennung zwischen Inhaltserstellung, Veröffentlichung und Präsentation der Inhaltselemente.
Der Begriff „Client“ kann ein Endpunktsystem in einem digitalen Netzwerk bezeichnen, das als Benutzerschnittstelle dient, um auf Informationen und Dienste aus einem Netzwerk anderer Systeme zuzugreifen, z.B. Zwischenspeichersysteme, Netzwerkserver, Back-End-Systeme, Speichersysteme und so weiter. Beispiele für Client-Systeme weisen einen Personal-Computer, eine Workstation, einen Tablet-Computer, ein Mobiltelefon oder eine beliebige andere mobile oder speziell dedizierte Einheit auf. In diesem Sinne kann auch eine Kamera mit einem Empfänger oder ein Bildschirm in einem Automobil mit zugehörigen Datenverarbeitungsressourcen ein Client sein.
Der Begriff „Content-Delivery-Network“ (CDN) oder Content-Distribution-Network kann ein geografisch verteiltes Netzwerk von Proxy-Servern und ihren zugehörigen Rechenzentren bezeichnen. Das Ziel kann darin bestehen, eine hohe Verfügbarkeit und eine hohe Leistung bereitzustellen, indem der Dienst bezogen auf die Endbenutzer räumlich verteilt ist. Somit kann eine bestimmte Gruppe von Benutzern ihre angeforderten Inhalte primär von einem bestimmten Rechenzentrum und nur ausnahmsweise von einem Backup-Rechenzentrum erhalten. Die Rechenzentren können digitale Inhalte in Form von herunterladbaren Objekten wie Mediendateien, Software, Dokumenten, Anwendungen, Live-Streaming-Daten, On-Demand-Streaming-Daten, Zugriff auf Social-Media-Seiten und so weiter bereitstellen.
Im Folgenden wird eine detaillierte Beschreibung der Figuren gegeben. Alle Anweisungen in den Figuren sind schematisch. Zuerst wird ein Blockschema einer Ausführungsform des erfindungsgemäßen von einem Computer umgesetzten Verfahrens zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems vorgestellt. Danach werden weitere Ausführungsformen sowie Ausführungsformen des Zwischenspeichersystems zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems beschrieben.
1 zeigt ein Blockschema einer bevorzugten Ausführungsform des von einem Computer umgesetzten Verfahrens 100 zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems. Das Content-Delivery-System kann auf verschiedenen Ebenen umgesetzt sein: dem Back-End-Server, der mittleren Schicht zum Zwischenspeichern und der Schicht der Informationsnutzung, d.h. dem Client. Somit ist das Content-Delivery-System zum Bereitstellen von Inhalten an ein Client-System geeignet. Das Verfahren weist ein Pflegen 102 eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart auf. Eine Inhaltsart kann sich - vereinfacht - auf alle Textinhaltselemente im Content-Delivery-System beziehen, und in einer komplexeren Umsetzung kann eine Inhaltsart (die möglicherweise auch Unterarten aufweist) entweder eine Teilmenge einer Inhaltsart aufweisen (z.B. Text in einem bestimmten Format oder zu einem bestimmten übergreifenden Thema) oder kann sich auf unterschiedliche Grund-Inhaltsarten beziehen und auf ein Inhaltsthema (z.B. Berichte, Bilder, Videoclips zu einer bestimmten Konferenz) fokussiert sein. Die Inhaltsarten können Text (Unterarten der Textart können unterschiedliche Formate für den Text aufweisen, z.B. das PDF-Format, das TXT-Format, das HTML-Format, das OpenDocument-Format usw.), Pixelgrafik oder Vektorgrafik, Tondateien, Videostreams sowie Ergebnisse von einer Suchmaschine, einer Datenbank usw. aufweisen.
Das Verfahren 100 weist auch ein Aktualisieren 106 des Seed-Wertes (der z.B. einer Versionsnummer oder einem Hash-Wert ähnelt) für die Gruppe von Inhaltselementen auf, wenn festgestellt wurde 104, dass eines der Inhaltselemente der Gruppe aktualisiert wurde.
Das Verfahren 100 weist auch ein Zwischenspeichern 108 eines (d.h. mindestens eines) der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem auf. Hier kann das Inhaltselement aus beliebigen Daten bestehen, die von einem Client-System (üblicherweise einem Browser, aber auch jeder anderen Daten empfangenden Anwendung) verarbeitbar sind, d.h. statischen Inhalten, dynamischen Inhalten, Listen von Suchergebnissen und dergleichen. Das Zwischenspeichersystem kann Teil des CDN sein, d.h. ein zugehöriger Verteilungsserver. Es sei jedoch auch angemerkt, dass der Verteilungsserver auch als Dienst des Hardwaresystems umgesetzt sein kann, das auch das Back-End-CMS-System ausführt. Dies kann von einer bestimmten Umsetzung der Konfiguration oder des CDN abhängen.
Darüber hinaus weist das Verfahren 100 auch ein Empfangen 110 einer API-Anforderung - insbesondere vom Client/zugehörigen Browser - auf, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist. Dieser Parameter, der verwendet wird, um den ausgewählten Seed-Wert wiederzugeben, würde als Erweiterung zu normalen, bereits bestehenden API-Aufrufen zwischen Clients und CDNs angesehen werden. Wenn herkömmliche API-Aufrufe verwendet werden, würde der Seed-Wert-Parameter fehlen, was bedeutet, dass sich der Zwischenspeicherserver wie unter herkömmlichen Bedingungen verhalten würde. Somit kann das neu vorgeschlagene Verfahren sowohl in herkömmlichen als auch in Computerumgebungen verwendet werden, die das hier vorgeschlagene Konzept unterstützen. Ein technischer Konflikt würde in keinem Fall hervorgerufen.
2 zeigt ein Blockschema einer Ausführungsform mit zwei CMSs in unterschiedlichen Rechenzentren, einem Zwischenspeichersystem 212 und eine Mehrzahl von Client-Systemen 218. Das Content-Delivery-Network kann beispielhaft ein erstes Rechenzentrum 202 und ein zweites Rechenzentrum 220 aufweisen. Beide Rechenzentren 202, 220 weisen jeweils ein Content-Management-System (nicht gezeigt) auf, wobei jedes eine Erstellungskomponente 204, 222 und eine Bereitstellungskomponente 208, 226 aufweist. Wenn ein Inhaltselement (nicht gezeigt) erstellt oder aktualisiert wurde, kann es von dem jeweiligen Erstellungssystem 204, 222 an das jeweilige Bereitstellungssystem 208, 226 freigegeben werden 206, 224. Jedes erstellte oder aktualisierte Inhaltselement (Cl) bzw. eine Gruppe, zu der die Inhaltselemente gehören, weist einen zugehörigen Seed-Wert auf. Ein erstelltes Inhaltselement kann den Seed-Wert 1234 für eine bestimmte Gruppe von Inhaltselementen aufweisen. Wenn das Inhaltselement aktualisiert (d.h. geändert) worden sein kann, kann der Seed-Wert ebenfalls aktualisiert werden, z.B. auf einen Wert 1235.
Ein entsprechendes Inhaltselement kann im zweiten Rechenzentrum 220 vorhanden sein. Spezielle Dienste können eine Synchronisierung zwischen der Erstellungskomponente 204 und der Erstellungskomponente 222 (siehe Bezugszeichen 228) sowie zwischen den Bereitstellungskomponenten 208 und 226 (siehe Bezugszeichen 230) ermöglichen. Der Seed-Wert für das noch nicht aktualisierte Inhaltselement im zweiten Rechenzentrum 220 kann z.B. 9876 sein, und nach einer Aktualisierung 9877. Die Synchronisierung zwischen den Komponenten kann anzeigen, dass ein bestimmtes Inhaltselement geändert worden sein kann. Auf dieser Grundlage kann der Seed-Wert für das zugehörige Inhaltselement in dem zweiten Rechenzentrum autonom geändert werden.
Weiter zeigt 2 einen Zwischenspeicherserver 212 als Teil des CDN, der zum Zwischenspeichern eines bestimmten Inhaltselements 214 und seines zugehörigen tatsächlichen Seed-Wertes geeignet ist. Wenn ein Client-System 218 über einen API-Aufruf und über die Netzwerkverbindung 216 ein bestimmtes Inhaltselement vom Zwischenspeichersystem 212 anfordert und das bestimmte Inhaltselement im Zwischenspeichersystem 212 nicht verfügbar ist, leitet das Zwischenspeichersystem 212 die Anforderung für das Inhaltselement (über einen API-Aufruf) über die Netzwerkverbindung 210 an das CMS im ersten Rechenzentrum weiter.
In diesem Zusammenhang fordert das Client-System 218 - zum Zweck der Aktualisierung eines Teils einer SPA - das Inhaltselement zusammen mit einem bestimmten Seed-Wert als zusätzlichem Parameter in der API-Anforderung an. Wenn der Seed-Wert in der API-Anforderung und der Seed-Wert des Inhaltselements 214 im Zwischenspeichersystem 212 gleich sind, muss bezüglich des Back-End-Systems nichts unternommen werden. Das Zwischenspeichersystem gibt den Seed-Wert einfach an den Client zurück. Wenn sich die beiden Seed-Werte unterscheiden, leitet das Zwischenspeichersystem 212 die Anforderung an das Back-End-System (d.h. das CMS) weiter und aktualisiert das Inhaltselement von dem Content-Management-Systems des Rechenzentrums 202. So wird der Netzwerkverkehr üblicherweise drastisch verringert.
Die allgemeine Idee besteht darin, Seed-Werte je Klassifizierung von Inhaltselementen, d.h. je Gruppe und/oder Inhaltsart, zu verfolgen. Der Seed-Wert muss die Rechenzentrums-ID und Klassifizierungsinformationen codieren. Eine einfache Form der Klassifizierung kann durch einen einzelnen Kleinbuchstaben erfolgen: c = Inhalt, a = Datenbestand and = Layout-Zuordnung, t = Art, i = Bildprofil, klein o = Sonstiges. Somit kann eine Anforderung nach einem Inhaltselement A von einem Rechenzentrum in Washington den Seed-Wert wdc:c:1234 aufweisen; analog würde ein Seed-Wert aus dem Frankfurter Rechenzentrum für Datenbestände als fra:a:5678 codiert werden. Um aggregierte Seed-Werte zu berechnen, kann eine XOR-Funktion verwendet werden. Wenn alle beteiligten Kleinbuchstaben in alphabetischer Reihenfolge sortiert werden, ist ein kombinierter Seed-Wert für Datenbestände und Inhalte (beispielhaft) fra:ac:9012. Ein derartiges Format, das als verborgener Seed-Wert verwendet werden könnte, der von einem Zwischenspeicher-Seed-Dienst erzeugt wird, würde Benutzern jedoch nicht sichtbar gemacht werden.
Auf diesen Zwischenspeicher-Seed-Dienst kann über einen bestimmten API-Aufruf des Zwischenspeicher-Seed-Dienstes zugegriffen werden. Ein Aufruf von einem Client-System zum Laden von Seed-Werten kann folgende Form haben:

GET/delivery/v1/seeds?classifications={classifications}
Eine JSON-Antwort (JavaScript Object Notation) kann dann einen zusammengeführten Seed-Wert für die gegebenen Klassifikationen sowie die einzelnen Seed-Werte je Klassifikation enthalten.

Ein weiteres Beispiel für die Zwischenspeicher-Seed-Dienst-API wäre ein Seed-Validierungsaufruf (abgefangen von einem Dispatcher):
Mindestens drei Fälle sind zu unterscheiden:
Fall 1: Zwischenspeicherfehler (Cache-Miss) am CDN
Der Client sendet einen Zwischenspeicher-Seed-Wert mit der Anforderung und ein Zwischenspeicherfehler tritt an dem CDN auf, z.B. dem Zwischenspeichersystem 212. Dann kann ein Dispatcher als Teil des Back-End-Servers (vgl. 3) die bereitgestellten Rechenzentrumsinformationen im Seed-Wert verwenden, um zu prüfen, ob der Seed-Wert im globalen Rechenzentrum erzeugt wurde. Wenn der bereitgestellte Seed-Wert mit dem aktuellen Seed-Wert übereinstimmt, kann der Dispatcher die API-Anforderung wie gewohnt versenden und die konfigurierten Cache-Header für die Edge-Steuerung (auf ein sehr langes Maximalalter) setzen.
Wenn der bereitgestellte Seed-Wert nicht übereinstimmt, ruft der Dispatcher den Zwischenspeicher-Seed-Dienst auf, um einen gültigen Seed für das aktuelle Rechenzentrum (über/validate...) zu erhalten, und sendet eine Umleitung für diese selbe URL, wobei er einfach den Seed-Wert durch den aktuellen Wert ersetzt. Es sei darauf hingewiesen, dass dies nur in sehr seltenen Fällen auftreten sollte (z.B. bei einem Rechenzentrum-Failover). Dadurch kann sicher vermieden werden, dass veraltete Zwischenspeicherdaten für einen neueren Seed-Wert für ein bestimmtes Inhaltselement (oder eine bestimmte Gruppe von Inhaltselementen), der in einem anderen Rechenzentrum erzeugt wurde, geliefert werden.
Fall 2: Abgelaufener Seed-Wert am CDN
Wenn ein Client 200 einen Zwischenspeicher-Seed-Wert mit der entsprechenden API-Anforderung sendet und ein abgelaufener Wert am Zwischenspeicher auf dem CDN vorliegt, kann der Dispatcher die Rechenzentrumsinformationen (wie zuvor) validieren, und im Falle einer Übereinstimmung kann der Dispatcher den eigentlichen API-Aufruf gefahrlos überspringen und stattdessen einen 304-Code „nicht geändert“ zurückgeben. Als Ergebnis wird das CDN darüber informiert, dass der Wert im Zwischenspeicher immer noch gültig ist, und das CDN fügt ihn wieder in seinen Ablauf-Zwischenspeicher ein. Andernfalls wird ein Umleitungsbefehl gesendet (derselbe wie im obigen Zwischenspeicherfehler-Arbeitsablauf).
Fall 3: Nicht abgelaufener Zwischenspeichertreffer (Cache-Hit) am CDN
In diesem Fall wird ein Ergebnis der API-Anforderung wie gewohnt vom CDN ausgeliefert.
3 zeigt ein Blockschema 300 einer Ausführungsform eines Datenflusses von einem CDN zu einem Inhaltsdienst, der von einem Zwischenspeicher-Seed-Dienst 310 unterstützt wird. Eine API-Anforderung kann am CDN eingehen 302, das von der Komponente 304 verwaltet wird, die beispielhaft ein AKAMAI-System sein kann (andere CDN-Verwaltungssysteme können ebenfalls verwendet werden). Die CDN-Verwaltungskomponente 304 sendet die Anforderung an den Back-End-Server. Der Back-End-Server weist einen Dispatcher 306 auf, von dem die Anforderung an einen bestimmten Dienst 308 zum Bereitstellen des Inhalts weitergeleitet wird. Parallel ruft der Dispatcher 306 den Zwischenspeicher-Seed-Dienst 310 auf. Wenn die Rechenzentrumsinformationen im Zwischenspeicher-Seed-Wert nicht mit dem aktuellen Rechenzentrum übereinstimmen, wird der Zwischenspeicher-Seed-Dienst aufgerufen und ein entsprechender Umleitungsbefehl gesendet. Ansonsten wird das Dispatching wie in herkömmlichen Systemen ausgeführt und ein Wert eines sehr langen Maximalalters gesendet.
Die Zwischenspeicher-Seed-Verwaltung auf Client-Seite kann wie folgt durchgeführt werden: Alle Clients können das Zwischenspeicher-Seed-Konzept ignorieren und als traditionelle Systeme arbeiten (Zwischenspeichern bleibt so schlecht wie bei bekannten Systemen). Die aktuellen Zwischenspeicher-Seed-Werte für bestimmte Inhaltselemente oder deren Klassen sind jedoch über einen öffentlichen API-Aufruf verfügbar. Die Zwischenspeicher-Seed-Werte werden auch im Rendering-Kontext „Seite“ verfügbar gemacht, sodass nachfolgende Anforderungen einen gültigen Seed-Wert verwenden können. Dem Client steht es frei, die Seed-Werte an geeigneten Zeitpunkten neu zu laden, z.B. in regelmäßigen Zeitintervallen (z.B. jede Minute) oder wenn dies durch eine von einem Benutzer betätigte Aktualisierungsschaltfläche ausgelöst wurde.
Ein Rechenzentrumswechsel - zugegebenermaßen ein seltener Fall - würde von der CDN-Verwaltungskomponente 304 abgewickelt. In einem üblichen Fluss können Anforderungen eines bestimmten Client jedoch immer an dasselbe Rechenzentrum weitergeleitet werden. Seed-Werte, die vom ersten Rechenzentrum erhalten werden, sind im zweiten Rechenzentrum nicht gültig, selbst wenn sie noch gültig sind; Infolgedessen kann der Client eine Umleitung zur Version des aktuellen Seed-Wertes eines zweiten Rechenzentrums (im obigen Beispiel vom ersten Rechenzentrum DC1:c:12352 DC'':C9877) erhalten.
Wenn ein Inhaltselement über lange Zeiträume nicht aktualisiert wurde, bleiben die Inhaltselemente auf den Zwischenspeichersystemen stabil, was bedeutet, dass das Zwischenspeichersystem keine Aktualisierung des Inhaltselements im Zwischenspeichersystem vom CMS nötig machen muss. Daher sollten nach einer Weile fast alle API-Aufrufe zu CDN-Zwischenspeichertreffern führen (d.h. die Inhaltselemente werden in den Zwischenspeichersystemen gefunden).
Das Client-System kann auch steuern, wie oft die Seed-Werte durch einen bestimmten Aufruf validiert werden. Infolgedessen, und wenn der aktuellste Seed-Wert als Parameter in der jeweiligen API-Anforderung verwendet wurde, ist die maximale Latenz die veröffentlichte Latenz (max-age).
4 zeigt ein Blockschema einer Ausführungsform des erfindungsgemäßen Zwischenspeichersystems 400 zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems. Das Content-Delivery-System ist auch hier zum Bereitstellen von Inhalten an ein Client-System geeignet. Das Zwischenspeichersystem weist Mittel - insbesondere eine geeignete Seed-Verwaltungseinheit (bzw. ein geeignetes Seed-Verwaltungsmodul) 402 - zum Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart und Mittel - insbesondere eine geeignete Aktualisierungseinheit (bzw. ein geeignetes Aktualisierungsmodul) 404 - zum Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen auf, wenn - durch eine Feststellungseinheit (oder ein Feststellungsmodul) 406 - festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde.
Darüber hinaus weist das Zwischenspeichersystem 400 Mittel - insbesondere eine geeignete Zwischenspeichereinheit (bzw. ein geeignetes Zwischenspeichermodul) - zum Zwischenspeichern eines Inhaltelements der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem und Mittel - insbesondere eine geeignete Empfängereinheit (bzw. ein geeignetes Empfängermodul) 408 - zum Empfangen einer API-Anforderung durch das Zwischenspeichersystem auf, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.
Ausführungsformen der Erfindung können zusammen mit fast jeder Art von Computer umgesetzt werden, unabhängig davon, ob die Plattform zum Speichern und/oder Ausführen eines bestimmten Programmcodes geeignet ist.
5 zeigt als Beispiel ein Computersystem 500 - insbesondere ein Zwischenspeichersystem -, das zum Ausführen von Programmcode im Zusammenhang mit dem vorgeschlagenen Verfahren geeignet ist.
Das Computersystem 500 ist nur ein Beispiel für ein geeignetes Computersystem und soll keine Einschränkung hinsichtlich des Anwendungsbereichs oder der Funktionalität von Ausführungsformen der hierin beschriebenen Erfindung nahe legen, unabhängig davon, ob das Computersystem 500 mit einer der oben dargelegten Funktionalitäten umgesetzt werden und/oder diese ausführen kann. In dem Computersystem 500 gibt es Komponenten, die mit zahlreichen anderen Allzweck- oder Spezial-Datenverarbeitungssystemumgebungen oder -konfigurationen verwendbar sind. Beispiele für bekannte Datenverarbeitungssysteme, -umgebungen und/oder -konfigurationen, die zur Verwendung mit dem Computersystem/Server 500 geeignet sein können, umfassen ohne Einschränkung Personal-Computer-Systeme, Server-Computersysteme, Thin Clients, Thick Clients, Handheld- oder Laptopeinheiten, Multiprozessorsysteme, mikroprozessorgestützte Systeme, Set-Top-Boxen, programmierbare Unterhaltungselektronik, Netzwerkcomputer, Minicomputersysteme, Mainframe-Computer-Systeme und verteilte Cloud-Computing-Umgebungen, die beliebige der oben genannten Systeme oder Einheiten umfassen, und dergleichen. Das Computersystem/der Server 500 kann im allgemeinen Kontext von durch das Computersystem ausführbaren Anweisungen beschrieben werden, beispielsweise Programmmodulen, die von dem Computersystem 500 ausgeführt werden. Im Allgemeinen können die Programmmodule Routinen, Programme, Objekte, Komponenten, Logik, Datenstrukturen usw. umfassen, die bestimmte Aufgaben ausführen oder bestimmte abstrakte Datentypen implementieren. Das Computersystem/der Server 500 kann in verteilten Cloud-Computing-Umgebungen betrieben werden, bei denen Aufgaben von Fernverarbeitungseinheiten ausgeführt werden, die über ein Datenübertragungsnetzwerk verbunden sind. In einer verteilten Cloud-Computing-Umgebung können sich Programmmodule sowohl auf lokalen als auch auf entfernt angeordneten Computersystem-Speichermedien wie beispielsweise Speichereinheiten befinden.
Wie in der Figur gezeigt, ist das Computersystem/der Server 500 in Form einer Allzweck-Datenverarbeitungseinheit gezeigt. Die Komponenten des Computersystems/Servers 500 können, ohne darauf beschränkt zu sein, einen oder mehrere Prozessoren oder Verarbeitungseinheiten 502, Systemspeicher 504 und einen Bus 506 umfassen, der verschiedene Systemkomponenten wie beispielsweise den Systemspeicher 504 und den Prozessor 502 verbindet. Der Bus 506 stellt eine oder mehrere von mehreren Arten von Busstrukturen dar, beispielsweise eines Speicherbusses bzw. eines Speichercontrollers, eines Peripheriebusses, eines Accelerated Graphics Port und eines Prozessor- bzw. lokalen Busses, unter Verwendung einer Vielfalt von Busarchitekturen. Beispielhaft und nicht einschränkend umfassen solche Architekturen einen ISA-Bus („Industry Standard Architecture“), einen MCA-Bus („Micro Channel Architecture“), einen EISA-Bus („Enhanced ISA“), einen lokalen VESA-Bus („Video Electronics Standards Association“) und einen PCI-Bus („Peripheral Component Interconnects“). Das Computersystem/der Server 500 umfasst üblicherweise eine Vielfalt von von einem Computersystem lesbare Medien. Solche Medien können alle verfügbaren Medien sein, auf die das Computersystem/der Server 500 zugreifen kann, und sie umfassen sowohl flüchtige als auch nichtflüchtige Medien, austauschbare und nicht austauschbare Medien.
Der Systemspeicher 504 kann vom Computersystem lesbare Medien in Form von flüchtigem Speicher umfassen, beispielsweise Direktzugriffsspeicher (RAM) 508 und/oder Cache-Speicher 510. Das Computersystem/der Server 500 kann ferner weitere austauschbare/nicht austauschbare, flüchtige/nichtflüchtige Speichermedien des Computersystems umfassen. Nur beispielhaft kann ein Speichersystem 512 zum Lesen von und Schreiben auf einem nicht austauschbaren, nichtflüchtigen magnetischen Medium (nicht gezeigt und üblicherweise als „Festplatte“ bezeichnet) vorgesehen sein. Obwohl nicht gezeigt, können ein Magnetplattenlaufwerk zum Lesen von und Schreiben auf einer austauschbaren, nichtflüchtigen Magnetplatte (z.B. einer „Diskette“) und ein Laufwerk für optische Platten zum Lesen von oder Schreiben auf einer austauschbaren, nichtflüchtigen optischen Platte wie einer CD-ROM, DVD-ROM oder eines anderen optischen Mediums vorgesehen sein. In solchen Fällen können diese jeweils über eine oder mehrere Medien-Datenschnittstellen mit dem Bus 506 verbunden sein. Wie nachstehend weiter gezeigt und beschrieben, kann der Speicher 504 mindestens ein Programmprodukt mit einem Satz von Programmmodulen (z.B. mindestens einem) enthalten, die zum Ausführen der Funktionen von Ausführungsformen der Erfindung konfiguriert sind.
Es können das Programm/der Dienst mit einem Satz von Programmmodulen 516 (mindestens einem) ebenso wie ein Betriebssystem, ein oder mehrere Anwendungsprogramme, andere Programmmodule und Programmdaten beispielhaft und nicht einschränkend im Speicher 504 gespeichert sein. Das Betriebssystem, das eine oder die mehreren Anwendungsprogramme, die anderen Programmmodule und die Programmdaten und/oder eine Kombination davon können eine Umsetzung einer Netzwerkumgebung umfassen. Die Programmmodule 516 führen im Allgemeinen die Funktionen und/oder Verfahren von Ausführungsformen der Erfindung wie hierin beschrieben aus.
Das Computersystem/der Server 500 kann auch mit einem oder mehreren externen Einheiten 518 Daten austauschen, beispielsweise einer Tastatur, einem Zeigegerät, einer Anzeige 520 usw.; einer oder mehreren Einheiten, die es einem Benutzer erlauben, mit dem Computersystem/Server 500 zu interagieren; und/oder einer oder mehreren Einheiten (z.B. einer Netzwerkkarte, einem Modem usw.), die es dem Computersystem/Server 500 erlauben, mit einem oder mehreren anderen Datenverarbeitungseinheiten Daten auszutauschen. Ein solcher Datenaustausch kann über Eingabe/Ausgabe-Schnittstellen (E/A-Schnittstellen) 514 erfolgen. Noch weiter kann das Computersystem/der Server 500 über einen Netzwerkadapter 522 mit einem oder mehreren Netzwerken wie einem lokalen Netzwerk (LAN), einem Weitverkehrsnetzwerk (WAN) und/oder einem öffentlichen Netzwerk (z.B. dem Internet) Daten austauschen. Wie gezeigt, kann der Netzwerkadapter 522 mit den anderen Komponenten des Computersystems/Servers 500 über den Bus 506 Daten austauschen. Es versteht sich, dass andere Hardware- und/oder Softwarekomponenten, obwohl nicht gezeigt, in Verbindung mit dem Computersystem/Server 500 verwendet werden könnten. Beispiele hierfür sind unter anderem: Mikrocode, Gerätetreiber, redundante Verarbeitungseinheiten, externe Festplattenarrays, RAID-Systeme, Bandlaufwerke und Datenarchivierungsspeichersysteme usw.
Weiter kann das Zwischenspeichersystem 400 zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems mit dem Bussystem 506 verbunden sein.
Die Beschreibung der verschiedenen Ausführungsformen der vorliegenden Erfindung wurde zu Zwecken der Veranschaulichung angegeben, ist aber nicht als erschöpfend oder auf die offenbarten Ausführungsformen beschränkt anzusehen. Viele Modifikationen und Varianten sind für Fachleute offensichtlich, ohne vom Umfang und Geist der beschriebenen Ausführungsformen abzuweichen. Die hier verwendete Terminologie wurde ausgewählt, um die Grundsätze der Ausführungsformen, die praktische Anwendung oder die technische Verbesserung gegenüber Technologien, die am Markt vorhanden sind, am besten zu beschreiben oder anderen Fachleuten zu ermöglichen, die hierin offenbarten Ausführungsformen zu verstehen.
Die vorliegende Erfindung kann als ein System, ein Verfahren und/oder ein Computerprogrammprodukt ausgeführt sein. Das Computerprogrammprodukt kann ein durch einen Computer lesbares Speichermedium (oder -medien) mit durch einen Computer lesbaren Programmanweisungen darauf umfassen, um einen Prozessor dazu zu veranlassen, Aspekte der vorliegenden Erfindung auszuführen.
Das Medium kann ein elektronisches, magnetisches, optisches, elektromagnetisches, Infrarotsystem oder ein Halbleitersystem für ein Ausbreitungsmedium sein. Beispiele für ein von einem Computer lesbares Medium können ein Halbleiter- bzw. Solid-State-Speicher, Magnetband, eine austauschbare Computerdiskette, Direktzugriffsspeicher (RAM), Nur-Lese-Speicher (ROM), eine starre Magnetplatte und eine optische Platte sein. Heutige Beispiele für optische Platten umfassen CD-ROM („Compact Disk Read Only Memory“), RD-RW („Compact Disk Read/Write“), DVD und Blu-Ray-Disk.
Bei dem durch einen Computer lesbaren Speichermedium kann es sich um eine physische Einheit handeln, die Anweisungen zur Verwendung durch ein System zur Ausführung von Anweisungen aufbewahren und speichern kann. Bei dem durch einen Computer lesbaren 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 durch einen Computer lesbaren Speichermediums gehören die Folgenden: eine tragbare Computerdiskette, eine Festplatte, ein Direktzugriffsspeicher (RAM), ein Nur-Lese-Speicher (ROM), ein löschbarer programmierbarer Nur-Lese-Speicher (EPROM bzw. Flash-Speicher), ein statischer Direktzugriffsspeicher (SRAM), ein tragbarer Kompaktspeicherplatte-Nur-Lese-Speicher (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 durch einen Computer lesbares 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. Lichtwellenleiterkabel durchlaufende Lichtimpulse) oder durch einen Draht übertragene elektrische Signale.
Hierin beschriebene, durch einen Computer lesbare Programmanweisungen können von einem durch einen Computer lesbaren Speichermedium auf jeweilige Datenverarbeitungs-/Verarbeitungseinheiten oder über ein Netzwerk wie zum Beispiel das Internet, ein lokales Netzwerk, ein Weitverkehrsnetz 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 durch einen Computer lesbare Programmanweisungen aus dem Netzwerk und leitet die durch einen Computer lesbaren Programmanweisungen zur Speicherung in einem durch einen Computer lesbaren Speichermedium innerhalb der entsprechenden Datenverarbeitungs-/Verarbeitungseinheit weiter.
Bei durch einen Computer lesbaren 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, zustandssetzende Daten oder entweder Quellcode oder 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 durch einen Computer lesbaren 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 fernen Computer oder vollständig auf dem fernen 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 Weitverkehrsnetz (WAN), oder die Verbindung kann mit einem externen Computer hergestellt werden (zum Beispiel über das Internet unter Verwendung eines Internet-Dienstanbieters). In einigen Ausführungsformen können elektronische Schaltungen, darunter zum Beispiel programmierbare Logikschaltungen, vor Ort programmierbare Gatter-Anordnungen (FPGA, field programmable gate arrays) oder programmierbare Logikanordnungen (PLA, programmable logic arrays) die durch einen Computer lesbaren Programmanweisungen ausführen, indem sie Zustandsinformationen der durch einen Computer lesbaren Programmanweisungen nutzen, um die elektronischen Schaltungen zu personalisieren, um Aspekte der vorliegenden Erfindung durchzuführen.
Aspekte der vorliegenden Erfindung sind 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 durch einen Computer lesbare Programmanweisungen ausgeführt werden können.
Diese durch einen Computer lesbaren Programmanweisungen können einem Prozessor eines Universalcomputers, eines Spezialcomputers oder einer anderen programmierbaren Datenverarbeitungsvorrichtung bereitgestellt werden, um eine Maschine zu erzeugen, so dass die über den Prozessor des Computers bzw. der anderen programmierbaren Datenverarbeitungsvorrichtung ausgeführten Anweisungen Mittel zur Umsetzung der in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte erzeugen. Diese durch einen Computer lesbaren Programmanweisungen können auch auf einem durch einen Computer lesbaren Speichermedium gespeichert sein, das einen Computer, eine programmierbare Datenverarbeitungsvorrichtung und/oder andere Einheiten so steuern kann, dass sie auf eine bestimmte Art funktionieren, so dass das durch einen Computer lesbare Speichermedium, auf dem Anweisungen gespeichert sind, ein Herstellungsprodukt aufweist, darunter Anweisungen, welche Aspekte der/des in dem Block bzw. den Blöcken des Ablaufplans und/oder der Blockschaubilder angegebenen Funktion/Schritts umsetzen.
Die durch einen Computer lesbaren Programmanweisungen können auch auf einen Computer, andere programmierbare Datenverarbeitungsvorrichtungen 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 auf einem Computer ausgeführten Prozess zu erzeugen, so dass die auf dem Computer, anderen programmierbaren Vorrichtungen oder einer anderen Einheit ausgeführten Anweisungen die in dem Block bzw. den Blöcken der Ablaufpläne und/oder der Blockschaubilder festgelegten Funktionen/Schritte umsetzen.
Die Ablaufpläne und/oder 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 zeigen, die eine oder mehrere ausführbare Anweisungen zur Ausführung der bestimmten logischen Funktion(en) aufweisen. In einigen alternativen Ausführungen können die in den Blöcken angegebenen Funktionen in einer anderen Reihenfolge als in den Figuren gezeigt stattfinden. Zwei nacheinander gezeigte Blöcke können zum Beispiel in Wirklichkeit im Wesentlichen gleichzeitig 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, welche die festgelegten Funktionen oder Schritte durchführen, oder Kombinationen aus Spezial-Hardware und Computeranweisungen ausführen.
Die hier verwendete Terminologie dient lediglich der Beschreibung bestimmter Ausführungsformen und soll die Erfindung nicht einschränken. Wie hierin verwendet, sollen die Singularformen „ein“ und „der/die/das“ auch die Pluralformen umfassen, es sei denn, der Kontext zeigt es deutlich anders an. Es versteht sich ferner, dass die Begriffe „weist auf“ und/oder „aufweisend“, wenn sie in dieser Beschreibung verwendet werden, das Vorhandensein von angegebenen Merkmalen, Ganzzahlen, Schritten, Vorgängen, Elementen und/oder Komponenten anzeigen, aber das Vorhandensein oder Hinzufügen von weiteren Merkmalen, Ganzzahlen, Schritten, Vorgängen, Elementen, Komponenten und/oder Gruppen davon nicht ausschließen.
Die entsprechenden Strukturen, Materialien, Vorgänge und Äquivalente aller Mittel oder Step-plus-Function-Elementen in den nachfolgenden Ansprüchen sollen jede Struktur, jedes Material oder jeden Vorgang zur Ausführung der Funktion in Kombination mit anderen beanspruchten Elementen, wie sie speziell beansprucht sind, umfassen. Die Beschreibung der vorliegenden Erfindung wurde zu Zwecken der Veranschaulichung und Beschreibung vorgestellt, soll für die Erfindung in der offenbarten Form jedoch nicht erschöpfend oder einschränkend sein. Viele Modifikationen und Varianten sind für Fachleute offensichtlich, ohne von dem Umfang und Geist der Erfindung abzuweichen. Die Ausführungsformen wurden gewählt und beschrieben, um die Grundsätze der Erfindung und der praktischen Anwendung am besten zu erläutern und es anderen Fachleuten zu ermöglichen, die Erfindung für verschiedene Ausführungsformen mit verschiedenen Modifikationen zu verstehen, die für die jeweilige betrachtete Verwendung geeignet sind.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 2017/0046438 A1 [0008]
US 2014/0372515 A1 [0009]

Claims

Von einem Computer umgesetztes Verfahren zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems, das zum Bereitstellen von Inhalten an ein Client-System geeignet ist, das Verfahren aufweisend - Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart, - wenn festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde, - Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen, - Zwischenspeichern eines der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem, - Empfangen einer API-Anforderung durch das Zwischenspeichersystem, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.
Verfahren nach Anspruch 1, ferner aufweisend - wenn ein Unterschied zwischen dem zugehörigen Seed-Wert und dem ausgewählten Seed-Wert bei dem Zwischenspeichersystem festgestellt wurde, Anfordern eines aktualisierten jeweiligen Inhaltselements als API-Anforderungsergebnis.
Verfahren nach einem der vorhergehenden Ansprüche, ferner aufweisend - regelmäßiges Empfangen einer API-Anforderung für das Inhaltselement der Gruppe bei dem Zwischenspeichersystem.
Verfahren nach einem der vorhergehenden Ansprüche, wobei die API-Anforderung als API-Anforderungsergebnis Inhalte von Elementen anfordert, die zu unterschiedlichen Gruppen von Inhaltselementarten gehören.
Verfahren nach Anspruch 4, wobei der Parameter der API-Anforderung ein Ergebnis einer XOR-Funktion ist, die die Seed-Werte der unterschiedlichen Arten als Eingabe hat.
Verfahren nach einem der vorhergehenden Ansprüche, ferner aufweisend - Verwenden eines Zeitwertes, der größer oder gleich einem vordefinierten Zwischenspeicher-Ablaufschwellenwert ist, als Zwischenspeicher-Ablaufzeit für ein Inhaltselement eines API-Anforderungsergebnisses bei dem Zwischenspeichersystem.
Verfahren nach einem der vorhergehenden Ansprüche, ferner aufweisend - Senden eines Zeitwertes als Zwischenspeicher-Ablaufzeit für ein Inhaltselement, der größer oder gleich einem vordefinierten Zwischenspeicher-Ablaufschwellenwert ist.
Verfahren nach einem der vorhergehenden Ansprüche, ferner aufweisend - Pushen einer Nachricht an das Client-System, wobei die Nachricht eine Aktualisierung eines Seed-Wertes anzeigt, der zu einem der Inhaltselemente einer Gruppe gehört.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das Inhaltselement ein Element einer Single-Page-Application (SPA) oder ein anderweitig dynamisch erzeugter Inhalt ist.
Verfahren nach einem der vorhergehenden Ansprüche, wobei das API-Anforderungsergebnis ein Ergebnis einer Suchanfrage ist.
Verfahren nach einem der vorhergehenden Ansprüche, das ferner vor dem Zwischenspeichern eines der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem aufweist: - Empfangen der API-Anforderung bei dem Zwischenspeichersystem, und - Anfordern des API-Anforderungsergebnisses.
Verfahren nach einem der vorhergehenden Ansprüche, wobei jeder der Seed-Werte der Inhaltsarten anforderbar ist.
Zwischenspeichersystem zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems, das zum Bereitstellen von Inhalten an ein Client-System geeignet ist, das Verfahren aufweisend - Mittel zum Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart, - Mittel zum Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen, wenn festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde, - Mittel zum Zwischenspeichern eines der Inhalte der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem, - Mittel zum Empfangen einer API-Anforderung durch das Zwischenspeichersystem, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.
Zwischenspeichersystem nach Anspruch 13, wobei das Zwischenspeichersystem aufweist - Mittel zum Anfordern eines aktualisierten jeweiligen Inhaltselements als API-Anforderungsergebnis, wenn bei dem Zwischenspeichersystem ein Unterschied zwischen dem zugehörigen Seed-Wert und dem ausgewählten Seed-Wert festgestellt wurde.
Zwischenspeichersystem nach Anspruch 13 oder 14, wobei die API-Anforderung als API-Anforderungsergebnis Inhalte von Elementen anfordert, die zu unterschiedlichen Gruppen von Inhaltselementarten gehören.
Zwischenspeichersystem nach Anspruch 15, wobei der Parameter der API-Anforderung ein Ergebnis einer XOR-Funktion ist, die die Seed-Werte der unterschiedlichen Arten als Eingabe hat.
Zwischenspeichersystem nach einem der Ansprüche 13 bis 16, ferner aufweisend - Mittel zum Verwenden eines Zeitwertes, der größer oder gleich einem vordefinierten Zwischenspeicher-Ablaufschwellenwert ist, als Zwischenspeicher-Ablaufzeit für ein Inhaltselement eines API-Anforderungsergebnisses bei dem Zwischenspeichersystem.
Zwischenspeichersystem nach einem der Ansprüche 13 bis 17, ferner aufweisend - Mittel zum Senden eines Zeitwertes als Zwischenspeicher-Ablaufzeit für ein Inhaltselement, der größer oder gleich einem vordefinierten Zwischenspeicher-Ablaufschwellenwert ist.
Zwischenspeichersystem nach einem der Ansprüche 13 bis 18, wobei das Zwischenspeichersystem eine mittlere Schicht eines dreistufigen Content-Delivery-Systems darstellt, das ein Content-Management-System, den Zwischenspeicherserver und ein Client-System aufweist.
Computerprogrammprodukt zum Verbessern der Zwischenspeicherfähigkeit eines API-Anforderungsergebnisses eines Content-Delivery-Systems, das zum Bereitstellen von Inhalten an ein Client-System geeignet ist, wobei das Computerprogrammprodukt ein von einem Computer lesbares Speichermedium mit darauf verkörperten Programmanweisungen aufweist, wobei die Programmanweisungen von einem oder mehreren Computersystemen oder Controllern ausführbar sind, um das eine oder die mehreren Computersysteme zu veranlassen zum - Pflegen eines eindeutigen Seed-Wertes je Gruppe von Inhaltselementen einer Inhaltsart - wenn festgestellt wurde, dass eines der Inhaltselemente der Gruppe aktualisiert wurde, - Aktualisieren des Seed-Wertes für die Gruppe von Inhaltselementen, - Zwischenspeichern eines der Inhaltselemente der Gruppe zusammen mit dem zugehörigen Seed-Wert in einem Zwischenspeichersystem, - Empfangen einer API-Anforderung durch das Zwischenspeichersystem, die als API-Anforderungsergebnis ein Inhaltselement der Gruppe anfordert, wobei ein Parameter der API-Anforderung ein ausgewählter Seed-Wert ist.