DE60225476T2

DE60225476T2 - Verfahren und vorrichtung zum netzwerk-caching

Info

Publication number: DE60225476T2
Application number: DE60225476T
Authority: DE
Inventors: Rajesh Winchester AGARWALLA; James Garrison CHALLENGER; George Winchester COPELAND; Arun Yorktown Heights IYENGAR; Mark Yorktown Heights LINEHAN; Subbarao Winchester MEDURI
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2001-12-19
Filing date: 2002-12-18
Publication date: 2009-03-12
Anticipated expiration: 2022-12-19
Also published as: WO2003053023A1; CN100465926C; CA2467933A1; US20030187935A1; EP1461928B1; AU2002350971A1; KR20040068108A; JP3978185B2; CN1605182A; EP1461928A1; ATE388566T1; JP2005513640A; US7730154B2; CA2467933C; KR100791430B1; DE60225476D1

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein verbessertes Datenverarbeitungssystem und insbesondere ein Datenverarbeitungssystem mit einer verbesserten Zuteilung von Netzwerk-Ressourcen. Genauer gesagt, die vorliegende Erfindung stellt ein Verfahren und ein System zur Zwischenspeicherung von Datenobjekten in einem Rechnernetzwerk bereit.
Der Erfindung zugrunde liegender allgemeiner Stand der Technik
Die Menge der Daten, die über das Internet übertragen werden, nimmt weiterhin mit einer Geschwindigkeit zu, die die Geschwindigkeit, mit der die Anzahl der Nutzer des Internet zunimmt, oder die Geschwindigkeit, mit der die Zahl ihrer Transaktionen zunimmt, überschreitet. Ein wesentlicher Faktor bei diesem Wachstum ist die sich verändernde Beschaffenheit der World-Wide-Websites selbst. In der Anfangsphase des World Wide Web bestanden Web-Seiten hauptsächlich aus statischem Inhalt wie zum Beispiel Text, Bildern und Verweisen (Links) auf andere Seiten. Der Dialogverkehr eines Benutzers mit einer Website beschränkte sich in seinem Umfang auf das Herunterladen einer HTML-Seite und ihrer Elemente. Da der Inhalt ungeachtet dessen, wer die Seite angefordert hat, gewöhnlich gleich war, war es für den Web-Server vergleichsweise einfach, zahlreiche Benutzer zu unterstützen. Gegenwärtig geht der Trend aber zu interaktiven Websites, bei denen sich der Inhalt und das Erscheinungsbild der Website als Reaktion auf bestimmte Benutzer und/oder eine bestimmte Benutzereingabe ändern. Dies gilt insbesondere für eCommerce-Sites, die die Auswahl und den Erwerb von Produkten im Rechnerdialog (online) unterstützen. Solche Sites unterscheiden sich von früheren Websites durch ihren größeren dynamischen Inhalt. Ein bekanntes Beispiel hierfür ist der "Online-Katalog", der auf vielen Websites von Unternehmen im Internet bereitgestellt wird. Jeder Kunde, der auf der Site angemeldet ist, um einen Kauf zu tätigen, hat die Möglichkeit, den Katalog durchzublättern und sogar ausführliche Informationen über Tausende von Produkten durchzusehen. Scheinbar muss der Webserver eine individuelle Webseite für jeden Käufer verwalten und aktualisieren. Internet-Benutzer erfreuen sich der Annehmlichkeit, die diese individuell anpassbaren interaktiven Websites bieten, und die Erwartungshaltung der Kunden wird der weiteren Verwendung von dynamischen Inhalten in Webseiten zweifellos weiteren Auftrieb geben.
Die aufkommende Verwendung von dynamischen Inhalten in Internet-Webseiten schafft für die Betreiber von Websites bestimmte logistische Probleme. Die heutigen eCommerce-Sites sind durch extrem hohe "Browse-to-buy-Quoten" gekennzeichnet, bei denen vor einem Kaufvorgang viele Produkte gesichtet werden. Bei Einkaufs-Sites beträgt das übliche Verhältnis 60 Interaktionen, bei denen keine dauerhaften Unternehmensdatensätze ("Anforderungen oder "Anfragen") aktualisiert werden, zu jeweils einer Interaktion, bei der dies geschieht ("Transaktionen") – das Durchsehen einer Produktbeschreibung ist ein Beispiel für eine Anforderung, während ein Kaufvorgang ein Beispiel für eine Transaktion ist.
Die steigende Verbreitung dynamischer Inhalte wirkt sich zum einen dahingehend aus, dass die Anzahl der Transaktionen zwar in einem vorhersagbaren und überschaubaren Maß steigt, die Anzahl der Anforderungen aber explosionsartig zunimmt. Die hohe Benutzer-Interaktivität von Webseiten, die dynamische Inhalte enthalten, ist für die große Zahl der Anforderungen je Transaktion verantwortlich. Der dynamische Inhalt in diesen Webseiten wird üblicherweise jedes Mal erzeugt, wenn ein Benutzer die Anforderung stellt, eine dieser Webseiten zu durchsuchen. Dies führt zu einem enormen Umfang an Inhalten, die erstellt und dem Benutzer während einer einzelnen Sitzung übermittelt werden müssen.
Die Erwartungshaltung der Benutzer zwingt den Site-Anbieter, als Reaktion auf deren Anforderungen sofort dynamische Web-Inhalte bereitzustellen. Wenn mögliche Kunden die Website als zu langsam wahrnehmen, werden sie die Site vielleicht nicht mehr besuchen, was eine Umsatzeinbuße zur Folge hat. Dem enormen Volumen des Internet-Verkehrs gerecht zu werden, kann jedoch eine sehr große finanzielle Belastung für ein im elektronischen Handel tätiges Unternehmen darstellen. Die einfachste Möglichkeit für ein im elektronischen Handel tätiges Unternehmen, den zunehmenden Bedarf an Informationen seitens möglicher Kunden zu decken, besteht darin, seine serverseitige Hardware durch die Erweiterung um zusätzliche Rechner, Speicherkapazität und Bandbreite zu verbessern. Diese Lösung kann jedoch unerschwinglich und unwirtschaftlich sein.
Eine kostengünstigere Vorgehensweise ist die Zwischenspeicherung, ein Verfahren, das bei digitalen Rechnern allgemein zur Anwendung kommt, um die Leistungsfähigkeit zu verbessern. Der in einem Rechner zur Datenspeicherung verwendete Hauptspeicher ist üblicherweise viel langsamer als der Prozessor. Um dem langsameren Speicher während eines Datenzugriffs Rechnung zu tragen, wird die normale Zeitsteuerung bei der Befehlsausführung des Prozessors üblicherweise um Wartezustände ergänzt. Wenn der Prozessor immer auf Daten aus dem Hauptspeicher zugreifen müsste, würde seine Leistungsfähigkeit erheblich in Mitleidenschaft gezogen werden. Bei der Zwischenspeicherung wird ein kleiner, aber äußerst schneller Speicherpuffer mit der Bezeichnung "Cachespeicher" verwendet, um den Vorteil einer statistischen Eigenschaft zu nutzen, die als "Datenlokalität" bezeichnet wird, um den Flaschenhals beim Zugriff auf den Hauptspeicher zu überwinden. Datenlokalität bezieht sich auf die verbreitete Tendenz, dass aufeinander folgende Datenzugriffe denselben allgemeinen Speicherbereich betreffen. Dies wird manchmal in Form von der "80/20"-Regel zum Ausdruck gebracht, bei der 80% der Datenzugriffe auf dieselben 20% des Speichers stattfinden.
Das folgende Beispiel bezieht sich zwar nicht auf das World Wide Web, veranschaulicht aber die Vorteile der Zwischenspeicherung im Allgemeinen. Nehmen wir an, eine Person verfügt über ein Rechnerprogramm, um zwei große Zahlenreihen zu multiplizieren, und diese Person möchte Möglichkeiten prüfen, in welcher Weise der Rechner modifiziert werden könnte, damit er das Programm schneller ausführen kann. Die einfachste Änderung bestünde darin, die Geschwindigkeit des Prozessors zu erhöhen, die aber Beschränkungen unterliegt. Jede einzelne Multiplizieroperation in dem Programm macht es erforderlich, dass der Prozessor zwei Operanden aus dem Speicher abruft, das Produkt berechnet und das Ergebnis anschließend in den Speicher zurückschreibt. Bei höheren Prozessor-Geschwindigkeiten wird die Zeit, die der Prozessor benötigt, um mit dem Speicher in Dialog zu treten, zu einem begrenzenden Faktor, da die für die Berechnung erforderliche Zeit an Bedeutung verliert. Obgleich ein schnellerer Speicher verwendet werden könnte, wäre die Nutzung eines großen Speichervolumens eines äußerst schnellen Speichers für den gesamten Speicherbedarf des Rechners zu unpraktisch und auch zu kostspielig. Glücklicherweise weist das Matrix-Multiplikationsprogramm eine hohe Datenlokalität auf, da die Elemente einer jeden der zwei Eingabematrizen aufeinander folgende Adressen in einem bestimmten Speicherbereich belegen. Statt ein großes Volumen eines äußerst schnellen Speichers zu verwenden, wird ein kleines Volumen eines solchen Speichers in Form von einem Cachespeicher verwendet. Beim Start des Programms werden die Eingabematrizen aus dem Hauptspeicher in den Cache-Pufferspeicher übertragen. Während der Ausführung des Programms ruft der Prozessor Operanden aus dem Cachespeicher ab und schreibt entsprechende Ergebnisse in den Cachespeicher zurück. Da Datenzugriffe den Hochgeschwindigkeits-Cachespeicher verwenden, kann der Prozessor das Programm wesentlich schneller ausführen, als wenn er den Hauptspeicher verwendet hätte. Tatsächlich hat die Verwendung des Cachespeichers eine Verbesserung der Geschwindigkeit zum Ergebnis, die fast so groß ist, wie wenn der gesamte Hauptspeicher erweitert worden wäre, jedoch zu wesentlich niedrigeren Kosten. Es sei angemerkt, dass ein Cachespeicher-System nur in Situationen vorteilhaft ist, in denen die Annahme der Datenlokalität gerechtfertigt ist; wenn der Prozessor häufig auf Daten außerhalb des Cachespeichers zugreifen muss, geht der Geschwindigkeitsvorteil des Cachespeichers verloren.
Ein weiteres Problem in Verbindung mit der Verwendung eines Daten-Cachespeichers ist die "Kohärenz des Cachespeichers". Wie vorstehend beschrieben wurde, werden Daten üblicherweise in einen Cachespeicher kopiert, um einen schnelleren Zugriff zu ermöglichen. Jedes Datum im Cachespeicher ist eine identische Kopie der ursprünglichen Version im Hauptspeicher. Ein Problem kann entstehen, wenn eine Anwendung in dem Rechner auf eine Variable im Hauptspeicher zugreift, während eine andere Anwendung auf die Kopie im Cachespeicher zugreift. Wenn eine der beiden Versionen der Variablen unabhängig von der jeweils anderen geändert wird, verliert der Cachespeicher seine Kohärenz, was möglicherweise negative Folgen hat. Wenn die Variable beispielsweise ein Zeiger auf kritische Daten des Betriebssystems ist, kann ein schwerwiegender Fehler auftreten. Um dies zu verhindern, muss der Zustand des Cachespeichers überwacht werden. Wenn Daten im Cachespeicher geändert werden, werden die "veralteten" Kopien im Hauptspeicher vorübergehend ungültig gemacht, bis sie aktualisiert werden können. Ein wichtiger Aspekt eines jeden Systems, das mit einem Cachespeicher ausgestattet ist, ist daher ein Prozess zur Wahrung der Kohärenz des Cachespeichers.
In Anbetracht dieser bekannten Probleme und Vorteile wurden Cachespeicher in Datenverarbeitungssystemen an verschiedenen Stellen im Internet oder in privaten Netzwerken, einschließlich so genannter Content Delivery Networks (CDNs), eingesetzt. Wie sich herausstellt, ist der Web-Verkehr für eine Zwischenspeicherung gut geeignet. Der Großteil des eCommerce-Verkehrs im Internet besteht aus Daten, die vom Server an den Benutzer gesendet werden, und nicht umgekehrt. In den meisten Fällen fordert der Benutzer Informationen von einer Website an, während er verhältnismäßig selten Informationen an die Website sendet. Beispielsweise fordert ein Benutzer häufig Webseiten an und übergibt verhältnismäßig selten persönliche Informationen oder Transaktionsinformationen, die auf der Website gespeichert werden. Daher weist der Großteil des Datenverkehrs positive Merkmale in Bezug auf die Kohärenz des Cachespeichers auf. Überdies weist der Großteil des Datenverkehrs auch positive Merkmale hinsichtlich der Datenlokalität auf, da ein Benutzer den Inhalt einer einzelnen Website gewöhnlich eine bestimmte Zeitlang durchsucht und dann erneut durchsucht, bevor er eine andere Website aufruft. Darüber hinaus fordern viele Benutzer üblicherweise dieselben Informationen an, und es wäre sinnvoller, die Informationen an einem bestimmten Punkt zwischenzuspeichern, als sie wiederholt aus einer Datenbank abzurufen. Auch können die meisten Web-Anwendungen einen gewissen Zeitversatz bei der Aktualität der Daten tolerieren. Wenn beispielsweise der Preis eines Produkts geändert wird, können ein paar Minuten Verzögerung, bis die Änderung wirksam wird, hinnehmbar sein, d. h., die Kohärenz des Cachespeichers muss nicht hundertprozentig perfekt sein, was eine Zwischenspeicherung ebenfalls wertvoller macht.
Die Vorteile der Zwischenspeicherung von Web-Inhalten können in der folgenden Erörterung grob aufgezeigt werden. Jede Anforderung von einem Client-Browser kann mehrere Datenverarbeitungssysteme durchlaufen, die sich überall im Internet befinden, wie zum Beispiel Zugangsschutzsysteme (Firewalls), Router und verschiedene Arten von Servern wie dazwischengeschaltete Server, Präsentations-Server (die z. B. statische Inhalte lesen, dynamische Seiten aufbauen), Anwendungs-Server (die z. B. Daten für Seiten abrufen, Aktualisierungen durchführen) und im Hintergrund laufende (Backend-)Server (z. B. für Datenbanken, Dienste und Legacy-Anwendungen). Mit jeder dieser Verarbeitungsstufen sind Erwägungen hinsichtlich des Preis/Leistungs-Verhältnisses verbunden.
Wenn überhaupt keine Zwischenspeicherung stattfindet, gelangen alle Anforderungen zu den Präsentationsservern, die einen Teil der Anforderungen erfüllen können, da sie keine dynamischen Inhalte benötigen. Leider erfordern viele Anforderungen jedoch auch eine Verarbeitung durch die Anwendungs- und die Backend-Server, um Aktualisierungen durchzuführen oder um Daten für Seiten mit dynamischen Inhalten zu erhalten.
Eine Anforderung braucht jedoch nur so weit übertragen zu werden, wie es zu ihrer Erfüllung notwendig ist, und die Leistungsfähigkeit kann mit der Verwendung von Cachespeichern erhöht werden, insbesondere auf der Site des Anbieters der Anwendung. Eine Zwischenspeicherung in einem dazwischengeschalteten Server kann beispielsweise einen Großteil der Anforderungen erfüllen, so dass nur ein kleiner Teil der Anforderungen zu den Präsentationsservern gelangt. Bei einer Zwischenspeicherung in den Präsentationsservern kann ein Teil der Anforderungen, die die Präsentations-Server erreichen, behandelt werden, so dass nur der kleinere Teil der Anforderungen zu den Anwendungs-Servern gelangt. Da ein Anwendungs-Server üblicherweise Transaktionen abwickelt, kann in einem Anwendungs-Server eine begrenzte Zwischenspeicherung vorgenommen werden. Insgesamt lassen sich bei einer angemessenen Verwendung von Cachespeichern auf der Site des Anbieters einer Anwendung jedoch beträchtliche Kosteneinsparungen erzielen.
In Anbetracht der Vorteile der Zwischenspeicherung kann man das Antwortverhalten einer Website, die dynamische Web-Inhalte enthält, verbessern, indem man von Zwischenspeicherungsverfahren Gebrauch macht, ohne große Investitionen in Server und andere Hardware, die vorstehend erwähnt wurde, zu tätigen. Ein wesentlicher Gesichtspunkt bei der Beantwortung der Frage, ob eine Zwischenspeicherung sinnvoll ist, ist die Häufigkeit, mit der sich der Web-Inhalt ändert. Im Allgemeinen stellt der Einsatz eines Cachespeichers eine brauchbare Lösung dar, wenn die Zugriffsrate zunimmt und die Aktualisierungsrate abnimmt. Genauer gesagt, die Zwischenspeicherung von Web-Inhalten ist machbar, wenn der Benutzer häufig statische Inhalte von einer Website abruft und selten Daten sendet, die auf der Website gespeichert werden sollen. Wenn die Website jedoch eine nicht unbeträchtliche Menge an dynamischen Inhalten umfasst, ist die Website zwangsläufig so konfiguriert, dass sich ihr Inhalt häufig ändert. In diesem Fall nimmt die Aktualisierungsrate eines Cachespeichers auf der Website stark zu, wodurch sich die Vorteile des Versuchs, den Inhalt der Website zwischenzuspeichern, aufheben.
Verschiedene Lösungen für eine wirksame Zwischenspeicherung von dynamischen Inhalten in Unternehmen wurden bereits vorgeschlagen und/oder realisiert. Diese Verfahren zur Zwischenspeicherung von Web-Inhalten in einem Web-Anwendungs-Server haben die Leistungsfähigkeit im Hinblick auf den Durchsatz und die Antwortzeiten erheblich verbessert.
Nachdem sich mit der Zwischenspeicherung von dynamischen Inhalten auf Websites für elektronische Geschäftsprozesse beträchtliche Vorteile erzielen ließen, wäre es von Vorteil, überall in den Netzwerken selbst Cachespeicher einzusetzen, die zusammenarbeiten, also eine so genannte "verteilte Zwischenspeicherung" zu realisieren, da sich mit einer näher am Benutzer erfolgenden Zwischenspeicherung von Inhalten wesentlich größere Vorteile bei der Antwort- oder der Latenzzeit erzielen lassen könnten. Bekannte Probleme bei der Zwischenspeicherung müssten jedoch bei einer Lösung in Form von einer verteilten Zwischenspeicherung berücksichtigt werden. Eine wahllose Platzierung und ein wahlloser Einsatz von Cachespeichern können die Leistungsfähigkeit zwar erhöhen, jedoch in einer Weise, die nicht gerade kostengünstig ist. Zu wichtigen Aspekten, die die Wirksamkeit eines Cachespeichers bestimmen, gehören seine Größe, die Länge des Trefferpfads des Cachespeichers, der zur Verwaltung des Inhalts des Cachespeichers erforderliche Arbeitsaufwand und die Entfernung zwischen dem Anforderer der Daten und dem Speicherort der Daten.
Was die Größe des Cachespeichers angeht, nimmt die Größe des Arbeits- und Plattenspeichers zwar weiterhin zu, doch ist deren Speicherbereich nie groß genug, als dass man seine Beschränkungen außer Acht lassen könnte. Anders ausgedrückt, ein Verfahren zur verteilten Zwischenspeicherung sollte nicht davon ausgehen, dass für einen Cachespeicher große Volumina an Arbeits- und Plattenspeicher zur Verfügung stehen, und der Bedarf an einem kleinen Cachespeicher ist allgemein dem Bedarf an einem großen Cachespeicher vorzuziehen. Überdies nimmt die Größe von Arbeits- und Plattenspeichern schneller zu, als sich ihre Bandbreite erhöht, und jeder Versuch, immer noch größere Datenmengen zwischenzuspeichern, wird letztlich durch Bandbreitenaspekte beschränkt.
Was die Länge des Trefferpfads eines Cachespeichers angeht, sollte eine Lösung in Form von einer verteilten Zwischenspeicherung vorzugsweise eine leichtgewichtige Anwendung zur Laufzeit umfassen, die problemlos eingesetzt werden kann, aber dennoch Cache-Treffer mit einem geringstmöglichen Verarbeitsaufwand feststellt, so dass der Durchsatz an Cache-Treffern sehr hoch ist. Die gewünschte Form einer verteilten Zwischenspeicherungsanwendung sollte nicht mit anderen Formen von verteilten Anwendungen verwechselt werden, die ebenfalls Daten nahe am Endbenutzer "zwischenspeichern". Anders ausgedrückt, es gibt andere Formen von Anwendungen, die von einer von vielen Möglichkeiten, Teile einer Anwendung und ihre zugehörigen Daten überall im Internet zu verteilen, profitieren. Eine komplette Anwendung und ihre zugehörigen Datenbanken können beispielsweise an verschiedenen Orten repliziert werden, und das Unternehmen, das sie einsetzt, kann die Datenbanken dann synchronisieren und die Anwendungen nach Bedarf verwalten. In anderen Fällen können der Nur-Lese-Anzeigeteil einer Anwendung und ihre zugehörigen Daten unter Verwendung von Zusatzprogrammen, JavaScript^TM oder ähnlichen Mechanismen auf clientbasierte Browser verteilt werden, während die Geschäftslogik auf einer geschützten Site eines Hostrechners bleibt.
Was den Arbeitsaufwand angeht, der zur Verwaltung des Inhalts von Cachespeichern erforderlich ist, verbessert eine Zwischenspeicherung in dem den Dienst anbietenden Unternehmen (serving enterprise) entweder den Durchsatz oder die Kostensituation, d. h., die Anzahl der Anforderungen, die pro Sekunde verarbeitet werden, oder den Umfang der benötigten Server-Hardware, da der Arbeitsaufwand je Anforderung geringer ist. In dem den Dienst anbietenden Unternehmen befindet sich der Cachespeicher vorzugsweise näher am Eintrittspunkt in das Unternehmen, da der Verarbeitungsaufwand durch alle Systeme in dem Unternehmen verringert wird und sich Verbesserungen dadurch noch stärker auswirken. Eine Zwischenspeicherung in der Nähe eines Zuteilers (dispatcher) kann wesentlich wirksamer sein als die Zwischenspeicherung in einem Anwendungs-Server. Eine Zwischenspeicherung in dem den Dienst anbietenden Unternehmen verbessert die Latenzzeit etwas, aber dies ist gewöhnlich von untergeordneter Bedeutung, da die Latenzzeit in dem den Dienst anbietenden Unternehmen üblicherweise viel geringer als die Latenzzeit im Internet ist. Überlegungen hinsichtlich eines robusten Verfahrens zur verteilten Zwischenspeicherung außerhalb des den Dienst anbietenden Unternehmens sind mit diesem und anderen Punkten verflochten.
Was die Entfernung zwischen dem Anforderer der Daten und dem Speicherort der Daten angeht, wird die vom Benutzer wahrnehmbare Latenzzeit im Internet vorrangig von der Entfernung zwischen dem Benutzer und dem Inhalt bestimmt. Diese Entfernung bemisst sich eher nach der Anzahl der Router-Überquerungen (routing hops) als nach der tatsächlichen physischen Entfernung. Wenn Inhalte an den "Grenzen" des Internet, wie beispielsweise den Internet-Diensteanbietern (Internet Service Providers, ISPs), zwischengespeichert werden, wird die vom Benutzer wahrnehmbare Latenzzeit deutlich verringert. Bei umfangreichen Inhalten, zum Beispiel Multimedia-Dateien, können die Anforderungen an die Bandbreite ebenfalls deutlich reduziert werden. Eine robuste Lösung zur verteilten Zwischenspeicherung sollte versuchen, Daten in unmittelbarer Nähe von Benutzern zwischenzuspeichern.
Da Benutzer geografisch überall verteilt sind, bedeutet eine benutzernahe Zwischenspeicherung von Inhalten, dass die Inhalte in mehreren Cachespeichern bei den ISPs und an den überall im Internet befindlichen Austauschstellen repliziert werden müssen. Im Allgemeinen kann dies die Kontrolle, die der Zwischenspeicherungsmechanismus über die Sicherheit des Inhalts und die Art und Weise, in der der Inhalt aktualisiert wird, ausübt, d. h. die Kohärenz des Cachespeichers, verringern. Ein kohärenter Cachespeicher lässt sich in einem den Dienst anbietenden Unternehmen verhältnismäßig einfach verwalten, wenn man berücksichtigt, dass der Zwischenspeicherungsmechanismus in dem den Dienst anbietenden Unternehmen augenscheinlich der Kontrolle einer einzigen Organisation unterliegt. Die Verwaltung von Cachespeichern sowohl innerhalb als auch außerhalb des den Dienst anbietenden Unternehmens macht es jedoch wesentlich schwieriger, die Kohärenz von Cachespeichern sicherzustellen und erhöht den hierzu erforderlichen Arbeitsaufwand erheblich. Obgleich die Überlegungen hinsichtlich der Sicherheit und der Kohärenz nahezu vernachlässigt werden können, wenn man Unternehmen, die digitale Inhalte verteilen, z. B. CDNs, nutzt, bei denen Speicherplatz im Cache gemietet und in einer wesentlich stärker kontrollierten Netzwerkumgebung als im öffentlichen Internet verwaltet wird, heben solche Lösungen einen Teil der Vorteile tatsächlich auf, die durch die Verwendung von offenen Standards durch das öffentliche Internet erzielt werden.
Vorzugsweise sollte ein Verfahren zur verteilten Zwischenspeicherung unter gewisser Beachtung der Unternehmensgrenzen, gleichzeitig jedoch auch überall im Internet in einer koordinierten Weise ausgeführt werden können. Darüber hinaus sollten Cachespeicher an vielen verschiedenen wichtigen Stellen entsprechend der erachteten Notwendigkeit eingesetzt werden können, beispielsweise in der Nähe eines Endbenutzers, z. B. in einem Client-Browser, in der Nähe eines Zuteilers eines den Dienst anbietenden Unternehmens, in einem Web-Anwendungs-Server oder an irgendeiner dazwischen liegenden Stelle. Ferner sollte das Verfahren Spezifikationen einhalten, so dass verschiedene Organisationen unterschiedliche Ausführungen einer Spezifikation zur verteilten Zwischenspeicherung entsprechend den lokalen Systemerfordernissen erstellen können.
Die Schwierigkeiten in Bezug auf eine möglicherweise robuste Lösung der verteilten Zwischenspeicherung werden durch den Trend, Webinhalte in Form von Fragmenten zu verfassen und zu veröffentlichen, noch verstärkt. Ein Teil des Inhalts wird in ein Fragment gestellt, und größere Inhalt-Einheiten (content entities) wie zum Beispiel Webseiten oder andere Dokumente bestehen aus Fragmenten, obgleich eine Inhalt-Einheit aus einem einzigen Fragment bestehen kann. Fragmente können getrennt gespeichert und dann bei Bedarf zu einer größeren Inhalt-Einheit zusammengesetzt werden.
Diese Vorteile zur Laufzeit werden durch die Komplexität bei anderen Aspekten der Verwaltung und Verwendung von Fragmenten aufgehoben. Fragmenten können unterschiedliche Lebensdauern zugewiesen werden, wodurch sie einen einheitlichen Mechanismus zum Ungültigmachen erfordern. Während Fragmente dazu verwendet werden können, statische Teile des Inhalts von dynamischen Teilen des Inhalts zu trennen, so dass der statische Inhalt wirksam zwischengespeichert werden kann, sieht man sich überdies den Schwierigkeiten in Verbindung mit der Zwischenspeicherung von dynamischen Inhalten gegenüber, wie vorstehend erörtert wurde. Von größter Bedeutung ist, dass die Zusammensetzung von Fragmenten auf Stellen innerhalb der Unternehmensgrenzen beschränkt worden ist.
Es wäre daher vorteilhaft, wenn man über ein robustes Verfahren zur verteilten Zwischenspeicherung verfügen würde, das die Zwischenspeicherung von Fragmenten und anderen Objekten unterstützt. Überdies wäre es besonders vorteilhaft, die Zusammensetzung von Fragmenten überall in einem Netzwerk an den Orten, an denen sich Cachespeicher befinden, nebeneinander stattfinden zu lassen, wobei den Unternehmensgrenzen je nachdem, wie man es für notwendig erachtet, entweder viel oder aber wenig Beachtung zukommt, wodurch die Verarbeitungslast für ein den Dienst anbietendes Unternehmen verringert und auf Wunsch zusätzliche Vorteile der verteilten Datenverarbeitung erzielt werden. Ferner wäre es vorteilhaft, wenn man über ein einheitliches Verfahren zur Namensgebung verfügen würde, so dass Fragmente überall im Internet eindeutig erkannt werden könnten, d. h., so dass die verteilten Cachespeicher einheitlich verwaltet werden würden.
Als eine weitere Überlegung hinsichtlich einer robusten Lösung für eine verteilte Zwischenspeicherung sollte jede mögliche Lösung den Aspekt der vorhandenen Programmiermodelle berücksichtigen. Man könnte beispielsweise ein Verfahren zur verteilten Zwischenspeicherung vorschlagen, das es erforderlich machen würde, das Programmiermodell eines vorhandenen Web-Anwendungs-Servers durch ein neues Programmiermodell zu ersetzen, das in Verbindung mit dem Verfahren zur verteilten Zwischenspeicherung arbeitet. Vorzugsweise würde eine Ausführung eines Verfahrens zur verteilten Zwischenspeicherung verschiedenen Programmiermodellen Rechnung tragen und dadurch die Bevorzugung von bestimmten Programmiermodellen vermeiden.
Es wäre vorteilhaft, wenn eine Ausführung des Verfahrens zur verteilten Zwischenspeicherung kleinere Cachespeicher für Fragmente zum Ergebnis hätte, die von leichtgewichtigen Prozessen in der üblichen Weise überall im Internet verwaltet werden könnten, wobei der Standort des Cachespeichers praktisch unberücksichtigt bleiben könnte. Darüber hinaus wäre es besonders vorteilhaft, wenn das Verfahren zur verteilten Zwischenspeicherung mit vorhandenen Programmiermodellen und Internet-Standards vereinbar wäre, so dass eine Ausführungsart des Verfahrens zur verteilten Zwischenspeicherung mit anderen Systemen gemeinsam betrieben werden könnte, die das Verfahren zur verteilten Zwischenspeicherung nicht einsetzen.
Die US-Patentschrift A-5 050 166 beschreibt ein Verfahren, das den Schritt des Empfangens einer Nachricht an einer Datenverarbeitungseinheit und den Schritt des Feststellens, ob ein Kopfbereich in der Nachricht angibt, dass sich die Nachricht auf ein Fragment bezieht, umfasst.
ZUSAMMENFASSUNG DER ERFINDUNG
Gemäß einer ersten Erscheinungsform stellt die vorliegende Erfindung ein Verfahren nach Anspruch 1 bereit.
Gemäß einer zweiten Erscheinungsform stellt die vorliegende Erfindung eine Datenverarbeitungseinheit nach Anspruch 9 bereit.
Die erste Nachricht hat beispielsweise für Cachespeicher- Verwaltungseinheiten, die keine Fragmente unterstützen, einen Hinweis darauf, dass das Fragment nicht zwischengespeichert werden kann, und für Cachespeicher-Verwaltungseinheiten, die Fragmente unterstützen, einen Hinweis darauf, dass das Fragment zwischengespeichert werden kann. Die erste Nachricht hat beispielsweise einen HTTP-Kopfbereich "Cache-Control" mit einer Anweisung für Cachespeicher-Verwaltungseinheiten, die keine Fragmente unterstützen, dass das Fragment nicht zwischengespeichert werden soll, und mit einer Anweisung für Cachespeicher-Verwaltungseinheiten, die Fragmente unterstützen, dass das Fragment zwischengespeichert werden soll.
Vorzugsweise wird auch festgestellt, dass ein Nachrichtenkopf in der ersten Nachricht angibt, dass ein Nachrichten-Hauptteil der ersten Nachricht ein Fragment ist.
Vorzugsweise wird das Fragment der ersten Nachricht in einem Cachespeicher abgelegt, der von einer Cachespeicher-Verwaltungseinheit in der Datenverarbeitungseinheit verwaltet wird, wobei die Cachespeicher-Verwaltungseinheit gleichermaßen zur Unterstützung von Fragment-Zwischenspeicherungsoperationen arbeitet, und zwar ungeachtet dessen, ob die Datenverarbeitungseinheit die Funktion eines Clients, eines Servers oder einer Verteilereinrichtung (hub), die sich überall im Netzwerk befinden, übernimmt.
Wenn an der Datenverarbeitungseinheit eine zweite Nachricht empfangen wird, die eine Anforderung für das Fragment umfasst, wird der Cachespeicher vorzugsweise durchsucht, und das Fragment wird aus dem Cachespeicher abgerufen. Das Fragment wird dann in einer dritten Nachricht an den Ersteller der zweiten Nachricht gesendet, ohne die zweite Nachricht an ihre Zieladresse zu senden.
Optional enthält die zweite Nachricht Informationen, die angeben, dass an der Datenverarbeitungseinheit keine Seitenzusammensetzungsoperation erforderlich ist, bevor die dritte Nachricht zurückgeschickt wird.
Optional verfügt die zweite Nachricht über einen Nachrichtenkopf mit einer Anweisung, die angibt, dass die dritte Nachricht von einer zweiten Datenverarbeitungseinheit empfangen wird, die über eine Cachespeicher-Verwaltungseinheit verfügt, welche Fragmente unterstützt.
Vorzugsweise wird an der Datenverarbeitungseinheit eine Seitenzusammensetzungsoperation durchgeführt, bevor die dritte Nachricht gesendet wird.
Vorzugsweise wird an der Datenverarbeitungseinheit eine Seitenzusammensetzungsoperation durchgeführt, um ein zusammengesetztes Fragment zu bilden. Beispielsweise wird festgestellt, ob das Fragment ein Fragment der obersten Ebene ist, das eine Verknüpfung zu einem Fragment der nächsten Ebene enthält. Daraufhin wird das Fragment der nächsten Ebene als Reaktion auf die Feststellung, dass das Fragment ein Fragment der obersten Ebene ist, welches eine Verknüpfung zu einem Fragment der nächsten Ebene enthält, abgerufen. Schließlich werden das Fragment der obersten Ebene und das Fragment der nächsten Ebene zusammengefasst und bilden ein zusammengesetztes Fragment.
Optional wird der Inhalt des Fragments der nächsten Ebene in den Inhalt des Fragments der obersten Ebene eingebettet. Des Weiteren kann aus einem Merkmalswert (property value) des Fragments der obersten Ebene und einem Merkmalswert des Fragments der nächsten Ebene ein Merkmalswert für das zusammengesetzte Fragment erzeugt werden. Auch kann aus einem Kopfbereichswert oder einer Anweisung des Fragments der obersten Ebene und einem Kopfbereichswert oder einer Anweisung des Fragments der nächsten Ebene ein Kopfbereichswert oder eine Anweisung für das zusammengesetzte Fragment berechnet werden.
Vorzugsweise wird eine vierte Nachricht erzeugt, die das zusammengesetzte Fragment enthält, wobei die vierte Nachricht eine HTTP-(Hypertext-Transport-Protocol-)Antwortnachricht ist.
Vorzugsweise wird für das Fragment der obersten Ebene und für das Fragment der nächsten Ebene eine kürzeste Verfallszeit ermittelt, und in der vierten Nachricht wird ein Kopfbereich "Expires" auf die kürzeste Verfallszeit gesetzt.
Alternativ wird für das Fragment der obersten Ebene und für das Fragment der nächsten Ebene ein geringstes Höchstalter ermittelt, und in der vierten Nachricht wird eine Anweisung "Cache-Control: max-age" auf das geringste Höchstalter gesetzt.
Optional wird für das Fragment der obersten Ebene und für das Fragment der nächsten Ebene eine Summe aus Inhaltlängenwerten berechnet, und in der vierten Nachricht wird ein Kopfbereich "Content-Length" auf die Summe der Inhaltlängenwerte gesetzt.
Optional wird für das Fragment der obersten Ebene und für das Fragment der nächsten Ebene ein letzter Änderungszeitpunkt ermittelt, und in der vierten Nachricht wird ein Kopfbereich "last modified" auf den letzten Änderungszeitpunkt gesetzt.
Optional wird eine Gruppe von Abhängigkeitskennungen aus der ersten Nachricht abgerufen, wobei eine Abhängigkeitskennung von einem Server erzeugt wird, von dem das Fragment stammt, und die Gruppe der Abhängigkeitskennungen wird in Verbindung mit einer Quellenkennung für das Fragment gespeichert. In diesem Fall kann optional eine Anforderungsnachricht für eine Ungültigmachung empfangen werden, aus der eine Abhängigkeitskennung abgerufen wird. Dadurch kann eine Gruppe von Fragmenten, die zu der Abhängigkeitskennung gehören, ermittelt werden, und folglich kann die ermittelte Gruppe von Fragmenten aus dem Cachespeicher gelöscht werden.
Vorzugsweise kann aus der ersten Nachricht eine Reihe von Regeln für die Zwischenspeicherung von Fragmenten ermittelt werden, und eine Cachespeicher-Kennung für das Fragment wird gemäß einer Regel für die Zwischenspeicherung von Fragmenten erzeugt. In diesem Fall beispielsweise kann das Fragment mit Hilfe der Cachespeicher-Kennung eindeutig erkannt werden. Darüber hinaus kann eine Speicheroperation unter Verwendung der erzeugten Cachespeicher-Kennung für das Fragment durchgeführt werden.
Optional wird mindestens ein Teil eines Pfades eines einheitlichen Bezeichners für Ressourcen (Uniform Resource Identifier, URI), der zu dem Fragment gehört, abgerufen, um eine Cachespeicher-Basiskennung zu bilden, und eine Regel für die Zwischenspeicherung von Fragmenten wird auf die Cachespeicher-Basiskennung angewendet, um eine Cachespeicher- Kennung für das Fragment zu bilden, wobei eine Regel für die Zwischenspeicherung von Fragmenten eine Gruppe von Namen von Abfrageparametern und/oder Namen von Cookies umfasst, die verwendet werden, um aus einem Namen und einem Wert bestehende Paare abzurufen, welche an die Cachespeicher-Basiskennung angefügt werden.
Gemäß einer vierten Erscheinungsform stellt die vorliegende Erfindung ein Verfahren nach Anspruch 17 bereit.
Gemäß einer fünften Erscheinungsform stellt die vorliegende Erfindung eine Einheit nach Anspruch 18 bereit.
Gemäß einer sechsten Erscheinungsform stellt die vorliegende Erfindung einen rechnerlesbaren Datenträger nach Anspruch 19 bereit.
Vorzugsweise ist ein Nachrichtenkopf, der einen Nachrichten-Hauptteil der Antwortnachricht angibt, ein Fragment, das in die Antwortnachricht eingefügt wird.
Vorzugsweise wird ein Nachrichtenkopf, der Cachespeicher-Verwaltungseinheiten, die keine Fragmente unterstützen, einen Hinweis darauf gibt, dass das Fragment nicht zwischengespeichert werden kann, und der Cachespeicher-Verwaltungseinheiten, die Fragmente unterstützen, einen Hinweis darauf gibt, dass das Fragment zwischengespeichert werden kann, in die Antwortnachricht eingefügt.
Gemäß einer bevorzugten Ausführungsform wird eine Datenstruktur festgelegt, die von einer Datenverarbeitungseinheit bei der Angabe einer Nachricht, welche über ein Netzwerk übertragen wird, verwendet wird, wobei die Datenstruktur Folgendes umfasst: einen Anzeiger, dass die Nachricht eine Anforderungsnachricht oder eine Antwortnachricht ist; und einen Fragment-Kopfbereich, der ein Schlüsselwort, das angibt, dass die Nachricht von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, verarbeitet werden soll, sowie eine oder mehrere Fragment-Kopfbereich-Anweisungen umfasst, die die Art und Weise angeben, in der die Nachricht verarbeitet werden soll.
Vorzugsweise befindet sich in der Datenverarbeitungseinheit eine Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt und gleichermaßen zur Unterstützung von Fragment-Zwischenspeicherungsoperationen arbeitet, und zwar ungeachtet dessen, ob die Datenverarbeitungseinheit die Funktion eines Clients, eines Servers oder einer Verteilereinrichtung, die sich überall im Netzwerk befinden, übernimmt.
Vorzugsweise hat die Datenstruktur nach Anspruch xx auch eine Fragment-Kopfbereich-Anweisung zur Aufnahme in eine Anforderungsnachricht, um anzugeben, dass eine Datenverarbeitungseinheit, die die Anforderungsnachricht verarbeitet hat, über eine Cachespeicher-Verwaltungseinheit verfügt, die Fragmente unterstützt.
Vorzugsweise hat die Datenstruktur eine Fragment-Kopfbereich-Anweisung zur Aufnahme in eine Antwortnachricht, um eine Gruppe von Abhängigkeitskennungen anzugeben, die von einem Ursprungsserver verwendet werden, um ein Fragment in der Antwortnachricht aus einem Cachespeicher zu löschen, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, verwaltet wird.
Vorzugsweise hat die Datenstruktur eine Fragment-Kopfbereich-Anweisung zur Aufnahme in eine Antwortnachricht, um eine Gruppe von Abhängigkeitskennungen anzugeben, die verwendet werden, um eine Cachespeicher-Kennung zu bilden, die ein Fragment in der Antwortnachricht eindeutig ausweist.
Optional ist die Anforderungsnachricht oder die Antwortnachricht eine HTTP-(Hypertext-Transport-Protocol-)Anforderungsnachricht oder eine HTTP-Antwortnachricht.
Gemäß einer bevorzugten Ausführungsform wird eine Datenstruktur bereitgestellt, die von einer Datenverarbeitungseinheit bei der Angabe eines Inhaltsobjekts verwendet wird, wobei die Datenstruktur Folgendes umfasst: eine Gruppe von Begrenzern für ein Element einer Auszeichnungssprache; ein Schlüsselwort, um anzugeben, dass das Element der Auszeichnungssprache eine Verknüpfung zu einem Fragment ist; und eine Quellenkennung für das Fragment, wobei die Quellenkennung von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, verwendet wird, um das Fragment abzurufen.
Vorzugsweise befindet sich in der Datenverarbeitungseinheit eine Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt und gleichermaßen zur Unterstützung von Fragment-Zwischenspeicherungsoperationen arbeitet, und zwar ungeachtet dessen, ob die Datenverarbeitungseinheit die Funktion eines Clients, eines Servers oder einer Verteilereinrichtung, die sich überall im Netzwerk befinden, übernimmt.
Vorzugsweise hat die Datenstruktur eine alternative Quellenkennung für das Fragment, wobei die alternative Quellenkennung von der Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, verwendet werden kann, um das Fragment abzurufen.
Vorzugsweise hat die Datenstruktur eine Gruppe von Abfrageparametern, die an die Quellenkennung angefügt werden.
Vorzugsweise handelt es sich bei der Auszeichnungssprache um SGML (Standard Generalized Markup Language). Vorzugsweise ist das Element der Auszeichnungssprache mit HTML (Hypertext Markup Language) kompatibel.
Ein Verfahren, ein System, eine Vorrichtung und ein Rechnerprogrammprodukt zur Zwischenspeicherung von Fragmenten werden vorgestellt. Nachdem eine Nachricht an einer Datenverarbeitungseinheit empfangen wurde, die eine Cachespeicher-Verwaltungseinheit enthält, wird ein Fragment im Nachrichtenhauptteil der Nachricht zwischengespeichert. Nachfolgende Anforderungen für das Fragment an der Cachespeicher-Verwaltungseinheit führen zu einem Cache-Treffer. Die Cachespeicher-Verwaltungseinheit arbeitet gleichermaßen zur Unterstützung von Fragment-Zwischenspeicherungsoperationen, und zwar ungeachtet dessen, ob die Datenverarbeitungseinheit die Funktion eines Clients, eines Servers oder einer Verteilereinrichtung, die sich überall im Netzwerk befinden, übernimmt; anders ausgedrückt, das Verfahren zur Zwischenspeicherung von Fragmenten ist im ganzen Netzwerk gleich.
Ein FRAGMENT-Kopfbereich wird zur Verwendung in einem Netzwerkprotokoll wie beispielsweise HTTP festgelegt; der Kopfbereich ordnet einem Fragment Metadaten für verschiedene Zwecke in Verbindung mit der Verarbeitung und der Zwischenspeicherung eines Fragments zu. Regeln für die Cachespeicher-Kennung (ID) gehen mit einem Fragment von einem Ursprungsserver einher; die Regeln für die Cachespeicher-Kennung beschreiben ein Verfahren zur Bildung einer eindeutigen Cachespeicher-Kennung für das Fragment, so dass dynamische Inhalte an einem von einem Ursprungsserver entfernten Ort zwischengespeichert werden können. Eine Cachespeicher-Kennung kann auf einer URI (Uniform Resource Identifier) für ein Fragment, aber auch auf Abfrageparametern und/oder Cookies beruhen. Abhängigkeitskennungen, die von einer Cachespeicher-Kennung oder einer URI für ein Fragment abweichen können, können einem Fragment zugeordnet werden, so dass ein Server eine Operation zum Ungültigmachen einleiten kann, die ein Fragment aus einem Cachespeicher löscht. Ein Auszeichnungselement (tag) 'FRAGMENTLINK' wird verwendet, um die Stelle in einer Seite für ein aufzunehmendes Fragment anzugeben, das während der Zusammensetzung der Seite oder während der Darstellung der Seite eingefügt werden soll.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die vorliegende Erfindung wird nun lediglich anhand eines Beispiels und mit Bezug auf eine bevorzugte Ausführungsform der Erfindung beschrieben, die in den beigefügten Zeichnungen veranschaulicht ist, bei denen:
1A ein typisches verteiltes Datenverarbeitungssystem zeigt, in dem eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann;
1B eine typische Rechnerarchitektur zeigt, die in einem Datenverarbeitungssystem verwendet werden kann, in dem eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann;
1C ein typisches verteiltes Datenverarbeitungssystem zeigt, wobei überall in dem verteilten Datenverarbeitungssystem Cachespeicher eingesetzt werden;
2 eine typische Webseite zeigt, die aus Fragmenten besteht;
3 eine formale Standard-Generalized-Markup-Language-(SGML-)Definition des FRAGMENTLINK-Auszeichnungselements gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
4 eine formale Definition des FRAGMENT-Kopfbereichs gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung ist;
die 5A bis 5G auf Objektabrufpfaden eine Gruppe von Agenten, die Fragmente unterstützen, sowie Agenten, die keine Fragmente unterstützen, zeigen;
6A eine Cachespeicher-Verwaltungseinheit für einen Cachespeicher, der Fragmente unterstützt, in einer Datenverarbeitungseinheit zeigt;
6B ein Flussdiagramm ist, das einen Prozess zeigt, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, bei der Verarbeitung von Antwortnachrichten, die Fragmente enthalten, verwendet werden kann;
6C ein Schritt eines Flussdiagramms ist, der ein bevorzugtes Verfahren zur Feststellung zeigt, ob ein Nachrichtenhauptteil ein Fragment-Objekt enthält;
6D ein Schritt eines Flussdiagramms ist, der ein spezielleres Verfahren zur Feststellung zeigt, ob ein Fragment-Objekt zwischengespeichert werden kann;
6E ein Schritt eines Flussdiagramms ist, der ein bevorzugtes Verfahren zur Feststellung zeigt, ob ein Fragment-Objekt zwischengespeichert werden kann;
6F ein Flussdiagramm ist, das ein Verfahren zur Feststellung zeigt, ob ein Fragment-Objekt an einer bestimmten Datenverarbeitungseinheit zwischengespeichert werden soll;
6G ein Schritt eines Flussdiagramms ist, der ein bevorzugtes Verfahren zur Feststellung zeigt, ob eine nachgelagerte Einheit (downstream device) über einen Cachespeicher verfügt, der Fragmente unterstützt;
6H ein Schritt eines Flussdiagramms ist, der ein spezielleres Verfahren zur Feststellung zeigt, ob das Fragment-Objekt, das gerade verarbeitet wird, nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet;
6I ein Schritt eines Flussdiagramms ist, der ein bevorzugtes Verfahren zur Feststellung zeigt, ob das Fragment- Objekt, das gerade verarbeitet wird, nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet;
6J ein Flussdiagramm ist, das ein Verfahren zur Feststellung zeigt, ob eine Seitenzusammensetzung erforderlich ist, bevor eine Antwortnachricht von der aktuellen Datenverarbeitungseinheit zurückgeschickt wird;
6K ein Schritt eines Flussdiagramms ist, der ein spezielleres Verfahren zur Feststellung zeigt, ob das Fragment-Objekt, das gerade verarbeitet wird, eine Verknüpfung zu einem anderen Fragment hat;
6L ein Schritt eines Flussdiagramms ist, der ein alternatives Verfahren zur Feststellung zeigt, ob das Fragment-Objekt, das gerade verarbeitet wird, eine Verknüpfung zu einem anderen Fragment hat;
6M ein Flussdiagramm ist, das einen Prozess zur Durchführung einer Seitenzusammensetzung zeigt;
6N ein Flussdiagramm ist, das einen Prozess zeigt, um eine Fragmentverknüpfung optional auf mehrere Fragmentverknüpfungen zu erweitern;
6O ein Schritt eines Flussdiagramms ist, der ein bevorzugtes Verfahren zur Feststellung zeigt, ob die Fragmentverknüpfung in dem aktuellen Fragment von der Antwortnachricht angibt, dass sie auf mehrere Fragmentverknüpfungen erweitert werden soll;
6P ein Flussdiagramm ist, das einen Prozess zeigt, um eine Fragmentverknüpfung gemäß Informationen, die zu der Fragmentverknüpfung gehören, auf mehrere Fragmentverknüpfungen zu erweitern;
6Q ein Flussdiagramm ist, das einen Prozess zeigt, um ein Fragment unter Verwendung einer Quellenkennung für das Fragment abzurufen;
6R ein Flussdiagramm ist, das einen Teil der Verarbeitung zeigt, die durchgeführt wird, wenn ein Fragment in einer Cachespeicher-Verwaltungseinheit zwischengespeichert wird, die Fragmente unterstützt;
6S ein Flussdiagramm ist, das einen Prozess zeigt, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, verwendet werden kann, um ein Fragment abzurufen, wenn es an einer Datenverarbeitungseinheit zwischengespeichert ist, welche die Cachespeicher-Verwaltungseinheit enthält;
6T ein Flussdiagramm ist, das einen Prozess zum Zusammenfassen von Kopfbereich-Werten und Merkmalswerten zeigt, die zu einer Vielzahl von Fragmenten gehören;
6U ein Flussdiagramm ist, das mehrere Schritte zeigt, die eine Reihe von Funktionen zum Zusammenfassen von Kopfbereich-Typen und Merkmalswerten darstellen;
6V ein Flussdiagramm ist, das einen Prozess zeigt, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, bei der Verarbeitung von Anforderungsnachrichten verwendet werden kann;
6W ein Flussdiagramm ist, das einen Prozess zeigt, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, bei der Verarbeitung von Nachrichten über Ungültigmachung gemäß einer Umsetzung einer bevorzugten Ausführungsform der vorliegenden Erfindung verwendet werden kann;
7A ein Blockschaltbild ist, das einen Teil des Datenflusses zwischen einem Web-Anwendungs-Server und einem Client zeigt, um zu veranschaulichen, wann manche Cachespeicher eine Zusammensetzung von Fragmenten durchführen;
7B ein Blockschaltbild ist, das einen Teil des Datenflusses zwischen einem Web-Anwendungs-Server und einem Client zeigt, um zu veranschaulichen, wie eine Gruppe von Einheiten angewiesen werden kann, Fragmente in einem Cachespeicher zwischenzuspeichern, der sich in nächster Nähe eines Endbenutzers oder einer Client-Einheit befindet;
die 8A bis 8D Datenflussdiagramme sind, die einen Teil der Verarbeitungsschritte zeigen, die in einem Client, einem dazwischengeschalteten Cachespeicher, der Fragmente unterstützt, oder einem Server stattfinden, um zu veranschaulichen, dass die Zwischenspeicherung von dynamischen aufgabenspezifischen oder kategoriespezifischen Inhalten mit Hilfe einer bevorzugten Ausführungsform der vorliegenden Erfindung durchgeführt werden kann;
9A ein Flussdiagramm ist, das einen Prozess zeigt, mittels dessen mehrere Fragmente in einer einzigen Anforderungsnachricht angegeben und anschließend verarbeitet werden können;
9B ein Flussdiagramm ist, das einen Prozess zeigt, mittels dessen eine einzelne Anforderungsnachricht an einer dazwischengeschalteten Cachespeicher-Verwaltungseinheit empfangen und anschließend verarbeitet werden kann;
9C ein Flussdiagramm ist, das einen Prozess an einem Web-Anwendungs-Server zeigt, der zur Verarbeitung einer Stapelverarbeitungsanforderungs-Nachricht für mehrere Fragmente dient;
die 10A bis 10D mehrere Beispiele sind, die die vorteilhafte Verringerung der Größe des Cachespeichers zeigen, die sich mit einer bevorzugten Ausführungsform der vorliegenden Erfindung erzielen lässt; und
die 11A bis 11H mehrere Diagramme sind, die die Art und Weise veranschaulichen, in der das Verfahren einer bevorzugten Ausführungsform der vorliegenden Erfindung eindeutige Cachespeicher-Kennungen erstellt und verwendet, um Fragmente zu verarbeiten und zu speichern.
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Die vorliegende Erfindung betrifft ein Verfahren zur verteilten Zwischenspeicherung von Fragmenten. Im Allgemeinen beinhalten die Einheiten, die eine bevorzugte Ausführungsform der vorliegenden Erfindung bilden oder zu ihr gehören können, viele verschiedene Datenverarbeitungstechnologien. Bevor eine bevorzugte Ausführungsform der vorliegenden Erfindung ausführlicher dargelegt wird, wird folglich als Hintergrundinformation ein typischer Aufbau von Hardware- und Softwarekomponenten in einem verteilten Datenverarbeitungssystem beschrieben.
Nun Bezug nehmend auf die Figuren zeigt 1A ein typisches Netzwerk aus Datenverarbeitungssystemen, wobei jedes Datenverarbeitungssystem einen Aspekt der bevorzugten Ausführungsform der vorliegenden Erfindung ausführen kann. Das verteilte Datenverarbeitungssystem 100 enthält das Netzwerk 101, bei dem es sich um ein Medium handelt, welches zur Bereitstellung von Datenübertragungsverbindungen zwischen verschiedenen Einheiten und Rechnern verwendet werden kann, die in dem verteilten Datenverarbeitungssystem 100 miteinander verbunden sind. Das Netzwerk 101 kann feste Verbindungen wie zum Beispiel Draht- oder Lichtwellenleiterkabel oder zeitweilige Verbindungen aufweisen, die über Telefon- oder drahtlose Übertragungen erfolgen. In dem gezeigten Beispiel sind der Server 102 und der Server 103 zusammen mit der Speichereinheit 104 an das Netzwerk 101 angeschlossen. Überdies sind auch die Clients 105 bis 107 an das Netzwerk 101 angeschlossen. Die Clients 105 bis 107 und die Server 102 bis 103 können von einer Vielzahl von Rechnereinheiten wie zum Beispiel Großrechnern, Personal Computern, persönlichen digitalen Assistenten (PDAs) usw. dargestellt werden. Das verteilte Datenverarbeitungssystem 100 kann zusätzliche Server, Clients, Router und andere Einheiten sowie Architekturen zwischen Gleichgestellten (Peer-zu-Peer-Architekturen) enthalten, die nicht gezeigt sind. Es sei angemerkt, dass das in 1A gezeigte verteilte Datenverarbeitungssystem als ein Datenverarbeitungssystem zu verstehen ist, das uneingeschränkt in der Lage ist, viele verschiedene Teilnetze unter Gleichgestellten und Dienste unter Gleichgestellten zu unterstützen.
In dem gezeigten Beispiel kann das verteilte Datenverarbeitungssystem 100 das Internet mit dem Netzwerk 101 enthalten, das einen weltweiten Verbund von Netzwerken und Verbindungsrechnern (Gateways) darstellt, die verschiedene Protokolle verwenden, um Daten miteinander auszutauschen, wie zum Beispiel das Lightweight Directory Access Protocol (LDAP), das Transport Control Protocol/Internet Protocol (TCP/IP), das HyperText Transport Protocol (HTTP), das Wireless Application Protocol (WAP) usw. Natürlich kann das verteilte Datenverarbeitungssystem 100 auch einige verschiedene Arten von Netzwerken wie zum Beispiel ein Intranet, ein lokales Netzwerk (LAN), ein drahtloses LAN oder ein Weitverkehrsnetz (WAN) enthalten. Der Server 102 unterstützt den Client 109 und das Netzwerk 110, das drahtlose Datenübertragungsverbindungen enthält, beispielsweise direkt. Das netzwerkfähige Telefon 111 ist über die drahtlose Verbindung 112 an das Netzwerk 110 angeschlossen, und der PDA 113 ist über die drahtlose Verbindung 114 an das Netzwerk 110 angeschlossen. Das Telefon 111 und der PDA 113 können mittels einer geeigneten Technologie wie zum Beispiel der drahtlosen Technologie Bluetooth^TM über die drahtlose Verbindung 115 auch direkt Daten miteinander austauschen, um so genannte Personal Area Networks (PAN) oder persönliche Ad-hoc-Netzwerke aufzubauen. Auf ähnliche Weise kann der PDA 113 Daten über die drahtlose Datenübertragungsverbindung 116 an den PDA 107 übertragen.
Die bevorzugte Ausführungsform der vorliegenden Erfindung könnte auf vielen verschiedenen Hardware-Plattformen realisiert werden; 1A ist als Beispiel einer heterogenen Datenverarbeitungsumgebung und nicht als architektonische Einschränkung der vorliegenden Erfindung zu verstehen. Es sei angemerkt, dass sich die nachfolgenden Beispiele insbesondere auf eine Client-Funktionalität und nicht auf eine Server-Funktionalität beziehen. Wie jedoch bekannt ist, weisen manche Datenverarbeitungseinheiten sowohl Client- als auch Server-Funktionalität auf, wie zum Beispiel Verteilereinrichtungen oder Datenverarbeitungseinheiten, d. h. gleichgestellte Datenverarbeitungseinheiten, in einem Netzwerk unter Gleichgestellten. Die bevorzugte Ausführungsform der vorliegenden Erfindung kann nach Bedarf auf Clients, Servern, gleichgestellten Datenverarbeitungseinheiten oder Verteilereinrichtungen realisiert werden.
Nun Bezug nehmend auf 1B zeigt eine Übersichtsdarstellung eine typische Rechnerarchitektur eines Datenverarbeitungssystems wie zum Beispiel eines der in 1A gezeigten Datenverarbeitungssysteme, in dem die bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann. Das Datenverarbeitungssystem 120 enthält eine oder mehrere Zentraleinheiten (CPUs) 122, die mit dem internen Systembus 123 verbunden sind, der den Speicher mit wahlfreiem Zugriff (RAM) 124, den Nur-Lese-Speicher 126 und den Eingabe-/Ausgabeadapter 128 miteinander verbindet, welcher wiederum verschiedene E/A-Einheiten wie zum Beispiel den Drucker 130, die Platteneinheiten 132 oder andere Einheiten, die nicht gezeigt sind, wie zum Beispiel ein Audioausgabesystem usw. unterstützt. Über den Systembus 123 ist auch der Datenübertragungsadapter 134 angeschlossen, der den Zugriff auf die Datenübertragungsverbindung 136 ermöglicht. Der Benutzerschnittstellenadapter 148 verbindet verschiedene Benutzereinheiten, wie zum Beispiel die Tastatur 140, die Maus 142 oder andere Einheiten, die nicht gezeigt sind, wie zum Beispiel einen berührungsempfindlichen Bildschirm, einen Stift oder ein Mikrofon. Der Bildschirmadapter 144 verbindet den Systembus 123 mit dem Bildschirm 146.
Der Fachmann versteht, dass die in 1B gezeigte Hardware in Abhängigkeit von der Ausführung des Systems unterschiedlich sein kann. Beispielsweise kann das System über einen oder mehrere Prozessoren, zum Beispiel einen auf dem Pentium^® von Intel^® beruhenden Prozessor, und einen digitalen Signalprozessor (DSP) sowie eine oder mehrere Arten eines flüchtigen und eines nichtflüchtigen Speichers verfügen. Zusätzlich zu oder anstelle der in 1B gezeigten Hardware können andere Peripheriegeräte verwendet werden. Anders ausgedrückt, der Fachmann würde davon ausgehen, dass er einige ähnliche Komponenten oder Architekturen in einem webfähigen oder netzwerkfähigen Telefon und in einem voll ausgestatteten Arbeitsplatzrechner vorfindet. Die gezeigten Beispiele sind nicht als architektonische Einschränkungen in Bezug auf eine bevorzugte Ausführungsform der vorliegenden Erfindung zu verstehen.
Die bevorzugte Ausführungsform der vorliegenden Erfindung kann nicht nur auf vielen verschiedenen Hardware-Plattformen, sondern auch in einer Vielzahl von Software-Umgebungen realisiert werden. Ein gewöhnliches Betriebssystem kann zur Steuerung der Programmausführung in jedem Datenverarbeitungssystem eingesetzt werden. So kann eine Einheit beispielsweise das Betriebssystem Linux^® ausführen, während eine andere Einheit eine einfache Java^®-Laufzeitumgebung enthält. Eine repräsentative Rechnerplattform kann einen Browser enthalten, bei dem es sich um eine bekannte Software-Anwendung zum Zugriff auf Dateien, Dokumente, Objekte oder andere Datenelemente in vielen verschiedenen Formaten und Codierungen wie zum Beispiel Grafikdateien, Textverarbeitungsdateien, Extensible-Markup-Language-(XML-), Hypertext-Markup-Language-(HTML-), Handheld-Device-Markup-Language-(HDML-), Wireless-Markup-Language-(WML-)Dateien handelt. Diese Objekte werden üblicherweise mit Hilfe eines Uniform Resource Identifier (URI) angesprochen. Die Gruppe der URIs umfasst Verweisadressen (Uniform Resource Locators, URLs) und einheitliche Namen für Ressourcen (Uniform Resource Names, URNs).
Nun Bezug nehmend auf 1C zeigt eine Übersichtsdarstellung ein typisches verteiltes Datenverarbeitungssystem, wie zum Beispiel das in 1A gezeigte, wobei überall in dem verteilten Datenverarbeitungssystem Cachespeicher realisiert sind. Das verteilte Datenverarbeitungssystem 150 enthält die Anforderungseinheit 152, die Anforderungen für Inhalte erzeugt. Die Anforderungseinheit 152 kann ein Internet-Diensteanbieter (ISP), der verschiedene private oder institutionelle Kunden bedient, oder ein Unternehmen sein, das den angeforderten Inhalt für verschiedene Zwecke verwendet. Wenn sich Daten, z. B. eine Anforderung, von der anfordernden Einheit (der Nutzungseinheit) zur antwortenden Einheit (der Bedieneinheit, z. B. einem Ursprungsserver) bewegen, werden sie als Daten beschrieben, die sich "stromaufwärts" ("upstream") bewegen. Wenn sich Daten, z. B. eine Antwort, von der antwortenden Einheit zur empfangenden Einheit bewegen, werden sie als Daten beschrieben, die sich "stromabwärts" ("downstream") bewegen.
Anforderungen von Client-Browsern 154 werden vom Zuteiler 156 weitergeleitet, der die Anforderungen über eine Gruppe von dazwischengeschalteten Servern 158 in dem Versuch, die Anforderungen zu erfüllen, gleichmäßig verteilt, bevor er sie am Internet-Austauschpunkt 160 über das Internet weitersendet. Jeder Browser 154 kann einen lokalen Cachespeicher verwalten, und jeder Server 158 unterstützt einen Weiterleitungs-Proxy-Zwischenspeicherungsmechanismus (forward proxy caching mechanism). Der Internet-Austauschpunkt 160 enthält auch die dazwischengeschalteten Server 162 und 164, die jeweils einen Cachespeicher verwalten können. Zu verschiedenen Erwägungen bei der Realisierung eines Cachespeichers in den Browsern 154 oder in den dazwischengeschalteten Servern 158, 160, 162 und 164 gehören die Verbesserung der Antwortzeiten und/oder die Verringerung der Bandbreite.
Anforderungen werden dann von dem Internet-Austauschpunkt 160 an den Zuteiler 166 geleitet, der sich in dem den Dienst anbietenden Unternehmen 168 befindet. Der Zuteiler 166 verteilt eingehende Anforderungen gleichmäßig über die dazwischengeschalteten Server 170, die versuchen, die Anforderungen zu erfüllen, bevor sie sie an den Zuteiler 172 weiterleiten; jeder dazwischengeschaltete Server 170 unterstützt einen umgekehrt funktionierenden Proxy-Zwischenspeicherungsmechanismus (reverse proxy caching mechanism). Nicht erfüllte Anforderungen werden vom Zuteiler 172 gleichmäßig über die Web-Anwendungs-Server 174 verteilt, die eine Anforderung in Verbindung mit Datenbankdiensten oder anderen Anwendungen, die auf die Datenbank 176 zugreifen, schließlich erfüllen können. Zu verschiedenen Erwägungen bei der Realisierung eines Cachespeichers in den dazwischengeschalteten Servern 170 oder in den Web-Anwendungs-Servern 174 gehören die Verbesserung des Durchsatzes und/oder die Senkung der Kosten.
Antworten werden in der umgekehrten Richtung von dem den Dienst anbietenden Unternehmen an eine Client-Einheit weitergeleitet. Es sei angemerkt, dass ähnliche dazwischengeschaltete Server in dem den Dienst nutzenden Unternehmen, im gesamten Internet oder in dem den Dienst anbietenden Unternehmen eingesetzt werden können. Es sei ferner angemerkt, dass jede nachfolgende vom Client entfernte Stufe, die eine Anforderung durchläuft, die wahrgenommene Antwortzeit weiter erhöht.
Die bevorzugte Ausführungsform der vorliegenden Erfindung kann auf einer Vielzahl von Hardware- und Software-Plattformen realisiert werden, wie vorstehend beschrieben wurde. Im Einzelnen betrifft die bevorzugte Ausführungsform der vorliegenden Erfindung jedoch ein Verfahren zur verteilten Zwischenspeicherung von Fragmenten. Bevor die bevorzugte Ausführungsform der vorliegenden Erfindung ausführlicher beschrieben wird, werden jedoch einige Hintergrundinformationen über statische und dynamische Web-Inhalte im Allgemeinen gegeben.
Das Format von Web-Seiten, die statische Inhalte in Form von Text und Grafiken enthalten, wird üblicherweise mit Hilfe von Auszeichnungssprachen wie zum Beispiel HTML angegeben. Die Auszeichnung besteht aus speziellen Codes oder Auszeichnungselementen, die die Anzeige von Wörtern und Bildern steuern, wenn die Seite von einem Internet-Browser gelesen wird. Java Server Pages (JSPs) und Servlets sind für Web-Seiten, die dynamische Inhalte enthalten, jedoch besser geeignet.
Im Grunde ist eine JSP ein Dokument in einer Auszeichnungssprache mit eingebetteten Befehlen, die beschreiben, wie eine Anforderung für die Seite verarbeitet werden soll, um eine Antwort zu erzeugen, die die Seite enthält. Die Beschreibung mischt den statischen Inhalt einer Schablone mit dynamischen Aktionen, die als Java-Code in einem einzigen Dokument ausgeführt werden. Bei Verwendung einer JSP kann man Java-Code auch als serverseitige Skriptlets in die Seite einbinden. Anders ausgedrückt, Java-Auszeichnungselemente werden auf einer Webseite angegeben und auf dem Webserver ausgeführt, um die Webseite zu ändern, bevor sie an den Benutzer gesendet wird, der sie angefordert hat. Diese Vorgehensweise ist geeignet, wenn der Umfang der Programmierlogik verhältnismäßig gering ist. Wenn sich im dem in der Auszeichnungssprache abgefassten Dokument mehr als eine geringfügige Menge an Programmierlogik befindet, hebt dies die Vorteile einer JSP auf: die Trennung der Präsentation eines Dokuments von der Geschäftslogik, die zu dem Dokument gehört. Um zu verhindern, dass übergroße Mengen an Code direkt in das in der Auszeichnungssprache verfasste Dokument eingebunden werden, bietet JSP die Möglichkeit, die Geschäftslogik in JavaBeans abzuspalten, auf die unter Verwendung von einfachen JSP-Auszeichnungselementen zur Laufzeit zugegriffen werden kann.
Genauer gesagt, eine JSP verwendet Auszeichnungselemente, die ähnlich einem Formatierungszeichen sind, und Skiptlets, die in der Programmiersprache Java geschrieben sind, um die Logik zu kapseln, die einen Teil oder den gesamten Inhalt für die Seite erzeugt. Die Anwendungslogik kann sich in serverbasierten Ressourcen wie zum Beispiel JavaBean-Komponenten befinden, auf die die Seite mit diesen Auszeichnungselementen und Skriptlets zugreift. Die Verwendung von Auszeichnungselementen einer Auszeichnungssprache ermöglicht es, nützliche Funktionen in einem in einer Auszeichnungssprache verfassten Dokument in einer vorteilhaften Form zu kapseln, die auch von Hilfsmitteln wie HTML-Seitenerstellungsprogrammen/-Editoren bearbeitet werden kann. Indem man die Geschäftslogik von der Präsentation trennt, wird eine wiederverwendbare, auf Komponenten beruhende Struktur unterstützt. Bei JSP können Autoren von Webseiten Module mit dynamischen Inhalten in statische HTML-Schablonen einfügen und auf diese Weise die Erzeugung von Web-Inhalten enorm vereinfachen. JSP ist ein wesentlicher Bestandteil des Programmiermodells Java Enterprise Edition (J2EE) von Sun.
Es sei angemerkt, dass die Beispiele der bevorzugten Ausführungsform der vorliegenden Erfindung, die nachstehend erörtert werden, JSPs verwenden können. Andere Arten von Server-Seiten, zum Beispiel die Active Server Pages (ASPs) von Microsoft, könnten jedoch ebenfalls verwendet werden.
Ein Produktanzeige-JSP gibt Daten über Produkte an. Eine Anforderung für ein bestimmtes Produkt, zum Beispiel einen Schraubenschlüssel, gibt diese JSP sowie eine Produktkennung als Abfrageparameter an. Eine Ausführung dieser JSP mit einem Parameter in Form von einer Produktkennung gibt eine HTML-Seite aus. Wenn sich die zugrunde liegenden Daten für dieses Produkt andern, wenn sich zum Beispiel der Preis für den Schraubenschlüssel erhöht, muss diese Seite ungültig gemacht werden. Dazu muss eine Abhängigkeit zwischen der Seite und den Daten hergestellt werden, indem man der Seite eine Abhängigkeitskennung, die die Daten darstellt, zuordnet.
Die Granularität ist ein Merkmal von Webseiten, das für eine wirksame Zwischenspeicherungsstrategie wichtig ist. Der Inhalt einer Webseite besteht aus mehreren Komponenten, von denen sich manche häufig ändern können, während andere verhältnismäßig statisch sind. Die Granulariät einer Webseite kann in Form von "Fragmenten" beschrieben werden, bei denen es sich um Teile des Inhalts handelt. Ein Fragment kann auf viele verschiedene Arten erzeugt werden, unter anderem, indem man eine HTTP-Anforderung für eine JSP-Datei erfüllt. In dem obigen Beispiel ist die Produktanzeige-Seite eine einzelne Fragmentseite.
Nun Bezug nehmend auf 2 zeigt eine Übersichtsdarstellung eine Webseite, die aus Fragmenten besteht. Dieses Beispiel zeigt, dass die Granularität von Fragmenten die Zwischenspeicherung von Teilen einer Seite ermöglicht, obgleich einige Fragmente unbeständig sind und bekanntermaßen in bestimmten Intervallen aktualisiert werden. Anders ausgedrückt, verschiedene Arten von Web-Inhalten profitieren in unterschiedlichem Maß von der Zwischenspeicherung.
Eine Produktanzeige-Webseite umfasst Fragmente 200 mit dynamischem Inhalt. Das Fragment der obersten Ebene ist eine Java Server Page (JSP) 204, die fünf Kindfragmente 206 bis 214 enthält. Die Fragmente 208 und 212 werden zwischengespeichert. Es sei angemerkt, dass die Kindfragmente von links nach rechts angeordnet werden, um die Änderungsgeschwindigkeit in ihren zugrunde liegenden Daten zu erhöhen, wie durch die Zeitachse in der Figur angegeben ist.
Die Produkt-URI 206 ist eine Verknüpfung in Form von einem einheitlichen Bezeichner für Ressourcen (Uniform Resource Identifier, URI) mit einer Graphics-Interchange-Format-(GIF- oder .gif-)Bilddatei des Produkts. Eine formatierte Tabelle kann eine ausführliche Produktbeschreibung 208 enthalten. Ein Fragment, das eine personalisierte Grußbotschaft 210 anzeigt, kann den Namen eines Käufers verwenden. Diese Grußbotschaft ändert sich häufig, zum Beispiel bei jedem Benutzer, es kann aber dennoch nützlich sein, sie zwischenzuspeichern, da der Name eines bestimmten Käufers im Laufe einer Sitzung von demselben Benutzer wieder verwendet wird.
Die JSP 212 erzeugt einen vereinfachten Einkaufswagen. Die Einkaufswagen-JSP 212 kann eine HTML-Tabelle erzeugen, um die Daten anzuzeigen. Dieser Inhalt ändert sich noch häufiger als die personalisierte Grußbotschaft 210, da er jedes Mal aktualisiert werden sollte, wenn der Käufer wieder etwas in seinen Einkaufswagen legt. Wenn der Einkaufswagen auf jeder Seite, die an den Käufer zurückgeschickt wird, erscheint, ist es dennoch sinnvoller, die JSP 212 zwischenzuspeichern, als dieselben Daten jedes Mal abzurufen, wenn der Einkaufswagen angezeigt wird. Die JSP 204 könnte auch Werbung 214 enthalten, die auf der Webseite erscheint, die eine Aktien-Beobachtungsliste anzeigt. Da sich die Werbung jedes Mal ändert, wenn die Seite angefordert wird, wäre die Aktualisierungsrate zu hoch, als dass man von einer Zwischenspeicherung profitieren würde.
Die 1A bis 2 zeigen verschiedene verteilte Datenverarbeitungssysteme und ein Beispiel für dynamischen Inhalt als Hintergrundkontext für die Erörterung der bevorzugten Ausführungsform der vorliegenden Erfindung. Wie vorstehend erwähnt wurde, kann es schwierig sein, Fragmente wirksam zwischenzuspeichern. Die bevorzugte Ausführungsform der vorliegenden Erfindung betrifft ein Verfahren, das HTML- und HTTP-Erweiterungen verwendet, um Fragmente wirksam zwischenzuspeichern, wobei der Überwindung der Schwierigkeiten in Verbindung mit der Zwischenspeicherung von dynamischen Fragmenten und personalisierten Fragmenten, d. h. dynamischem Inhalt, besondere Beachtung geschenkt wird.
Es sei angemerkt, dass in den nachstehend aufgeführten Beispielen bestimmte Spezifikationen von Protokollen, zum Beispiel HTTP/1.1 und HTML 4.1, erwähnt werden. Der Fachmann versteht jedoch, dass andere Protokolle ebenfalls verwendet werden könnten, die das Minimum an gleichwertigen Merkmalen und Funktionen bereitstellen, welches von der bevorzugten Ausführungsform der vorliegenden Erfindung benötigt wird.
Terminologie
Ein "statisches Fragment" wird als ein Fragment definiert, das ohne Verwendung von Abfrageparametern oder Cookies abgerufen werden kann. Auf ein statisches Fragment kann vollkommen anhand seiner URI verwiesen werden, es kann zwischengespeichert und/oder abgerufen werden.
Ein "dynamisches Fragment" ist ein Fragment, das als Ergebnis einer Berechnung am Server erzeugt wird, die auf den vom Anforderer gelieferten Parametern oder Cookies beruht. Ein Beispiel für ein dynamisches Fragment könnten die Ergebnisse eines Sportereignisses sein. Ein dynamisches Fragment ist dadurch gekennzeichnet, dass es aus einer vom Benutzer angeforderten Teilmenge an Daten besteht, die für eine Website spezifisch sind.
Ein "personalisiertes Fragment" wird ebenfalls als Ergebnis einer Berechnung erzeugt, die auf den Parametern oder Cookies des Anforderers beruht. Ein personalisiertes Fragment ist ein spezieller Fall eines dynamischen Fragments, da sein Inhalt vom Benutzer abhängt. Ein personalisiertes Fragment kann beständig sein, z. B. eine Kontonummer, oder unbeständig, z. B. ein Einkaufskorb. Bei der Definition und Verwaltung von Fragmenten stellen dynamische und personalisierte Fragmente gleiche Probleme dar; folglich werden die Begriffe "dynamisch" und "personalisiert" austauschbar verwendet.
Ein "Fragment der obersten Ebene" ist ein Fragment, das nicht in ein anderes Fragment eingebettet ist, sondern das selbst andere Fragmente aufnehmen kann.
Ein Seitenzusammensetzungsprogramm ("page assembler") ist ein Programm, das eine Seite aus Fragmenten zusammenstellt. Der Vorgang des Erfassens von Fragmenten und des Zusammenstellens einer Seite wird als "Seitenzusammensetzung" bezeichnet. Der Vorgang des Prüfens eines Fragments, um festzustellen, ob weitere Fragmente abgerufen und zu dem Dokument zusammengesetzt werden sollen, wird nachstehend als "Zerlegung" ("parsing") bezeichnet, selbst wenn keine Zerlegung im wörtlichen Sinn durchgeführt wird. Ein Fragment kann zum Beispiel mit Metainformationen einhergehen, die zusätzliche Fragmente benennen, welche zur Zusammensetzung abgerufen werden sollen, und die die genauen Stellen angeben, an denen die zusätzlichen Fragmente eingefügt werden sollen; das Prüfen eines solchen Fragments auf zusätzliche Fragmente ist nicht unbedingt eine formale Zerlegung, wie sie in der Informatik durchgeführt wird.
Definition eines FRAGMENTLINK-Auszeichnungselements
Nun Bezug nehmend auf 3 wird eine formale Standard-Generalized-Markup-Language-(SGML-)Definition des FRAGMENTLINK-Auszeichnungselements gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung angegeben. Ein FRAGMENTLINK-Auszeichnungselement wird verwendet, um die Stelle eines Fragments anzugeben, das während der Zusammensetzung der Seite oder während der Darstellung der Seite in das Dokument eingefügt werden soll. Das neue Objekt wird als Teil des Elterndokuments zerlegt und kann eigene FRAGMENTLINK-Auszeichnungselemente enthalten. Die Definitionen der Attribute des FRAGMENTLINK-Auszeichnungselements werden nachstehend erörtert.
(Es sei angemerkt, dass Auszeichnungssprachen üblicherweise spitze Klammern ("<" und ">") als Begrenzer verwenden. Um mögliche Formatierungsprobleme oder Probleme bei der elektronischen Interpretation der Versionen der in diesem Dokument verwendeten Auszeichnungssprachen zu vermeiden, wurden überall in diesem Dokument ersatzweise geschweifte Klammern ("{" und "}") als Begrenzer verwendet. Als ein weiterer Formatierungshinweis sei erwähnt, dass manche Beispiele von langen Zeichenketten mehr als eine Textzeile in diesem Dokument beanspruchen; der Fachmann könnte feststellen, welche Text-Beispiele als Beispiel für eine einzelne Textzeile vorgesehen waren, obwohl sie in dem Dokument als über die Zeilengrenzen hinausgehende Textzeilen erscheinen.)

src=URI
Das Attribut SRC gibt den Ursprungsort des Fragments an, das in das Dokument eingefügt werden soll; das Attribut SRC hat die Funktion einer Quellenkennung, um das Fragment abzurufen. Wenn die URI eine relative URI ist, wird bei einer absoluten URI vom Pfad des Elterndokuments und entsprechenden BASE-Auszeichnungselementen ausgegangen. Es sei angemerkt, dass dies zu Irritationen führen kann, wenn ein einzelnes gewöhnliches Fragment auf zwei verschiedenen Seiten enthalten ist. Es wird empfohlen, dass Autoren nur absolute Pfadnamen für die Fragment-URI codieren. Der Protokollteil der URI kann "cookie" angeben, wobei der Wert des eingefügten Texts in diesem Fall von dem benannten Cookie übernommen wird.

alt=string
Das Attribut ALT gibt einen alternativen HTML-Text an, der in dem Fall, in dem die URI vom Attribut SRC nicht abgerufen werden kann, als Ersatz dienen soll. Wenn kein Attribut ALT angegeben wird und das Fragment des Attributs SRC nicht abgerufen werden kann, wird kein Fragment abgerufen.

parms=%parmlist
Das Attribut PARMS gibt eine Liste von Namen mit fester Länge an. Jeder Name entspricht einem Abfrageparameter, der in der URI des Elternfragments vorhanden sein kann. Wenn das Attribut PARMS angegeben wird, wird die in dem Attribut SRC angegebene URI als unvollständig betrachtet. Um das Attribut SRC zu vervollständigen, sollten die Werte eines jeden der im Attribut PARMS bezeichneten Abfrageparameter aus dem Elterndokument abgerufen und zur Erzeugung eines aus einem Namen und einem Wert bestehenden Paares verwendet werden. Dieses Namen-Wert-Paar soll an die URI des Attributs SRC als Abfrageparameter angefügt werden, um sie zu vervollständigen. Wenn der bezeichnete Parameter nicht in der Eltern-URI vorhanden ist, wird der Parameter nicht an die URI des Fragments angefügt. Jeder Parameter sollte in der gleichen Reihenfolge, in der er im Attribut PARMS erscheint, an die URI des Attributs SRC angefügt werden.

foreach=quoted-string
Das Attribut FOREACH gibt eine zitierte Zeichenkette an. Der Wert der zitierten Zeichenkette ist vorzugsweise der Name eines Cookie, dessen Wert eine Liste mit Namen-Wert-Paaren fester Länge ist, wobei der Name und der Wert durch ein Gleichheitszeichen ("=") oder durch eine andere Art eines gleichwertigen Begrenzers getrennt werden. Für jedes Namen-Wert-Paar in dem Cookie wird ein neues FRAGMENTLINK-Auszeichnungselement erzeugt, dessen Attribut SRC die URI ist, wobei das Namen-Wert-Paar als Abfrageparameter hinzugefügt wird. Dies stellt eine verkürzte Schreibweise zur automatischen Erzeugung von mehreren FRAGMENTLINK-Auszeichnungselementen dar, die sich nur im Wert von einem einzigen Abfrageparameter, z. B. der Aktien-Beobachtungsliste eines Benutzers, unterscheiden.
Anders ausgedrückt, das Attribut FOREACH ermöglicht es, eine einzelne Verknüpfung mit einem Fragment auf eine Gruppe von mehreren Verknüpfungen mit mehreren Fragmenten zu erweitern. Jedes Namen-Wert-Paar wird ein Paar eines Erweiterungsparameter-Namens und eines Erweiterungsparameter-Werts.

showlink=(no|comment|CDATA)
Das Attribut SHOWLINK gibt den Namen des Auszeichnungselements an, das verwendet wird, um einen Zeilenumbruch an den enthaltenen Fragmentdaten durchzuführen. Wenn es mit "nein" ("no") angegeben ist, werden die Daten ohne Auszeichnungselement für einen Zeilenumbruch aufgenommen. Wenn es als "Kommentar" ("comment") angegeben ist, wird das FRAGMENTLINK-Auszeichnungselement als ein HTML-Kommentar zurückgeschrieben. Wenn es als ein anderer Wert angegeben ist, wird das FRAGMENTLINK-Auszeichnungselement als das angegebene Auszeichnungselement zurückgeschrieben. Es wird keine Prüfung durchgeführt, um sicherzustellen, dass CDATA ein gültiges Auszeichnungselement ist, so dass die Entscheidung, wie das Fragment genau bezeichnet werden soll, dem Autor der Seite überlassen bleibt. Wenn das Attribut SHOWLINK weggelassen wird, wird kein Zeilenumbruch durchgeführt.

id=ID
Wenn das Attribut ID angegeben wird, wird sein Kennwert gemäß der "HTML 4.01 Spezification", W3C Recommendation, 24. Dezember 1999, die durch Bezugnahme Bestandteil hiervon ist und von der Website des World Wide Web Consortium (W3C) unter www.w3c.org abgerufen werden kann, dem Fragment in dem sich ergebenden DOM-Element, das dieses Fragment darstellt, als ein eindeutiger Name zugewiesen.

class=CDATA
Wenn das Attribut CLASS angegeben wird, weist es gemäß der HTML-Spezifikation dem DOM-Element, das dieses Fragment darstellt, einen Klassennamen oder eine Gruppe von Klassennamen zu.
Wenn eine Seite zusammengesetzt wird, ruft das Seitenzusammensetzungs-Programm das angegebene Fragment ab und fügt es in das Elternobjekt ein. Mittels des Attributs SHOWLINK kann gestattet werden, dass an den eingefügten Daten in einem Auszeichnungselement oder einem HTML-Kommentar ein Zeilenumbruch durchgeführt wird. Verschachtelte Fragmente sind vorgesehen, aber kein Fragment kann sich selbst direkt oder indirekt enthalten. Die Verschachtelungsstruktur von allen Fragmenten in einem Fragmentraum sollte einen gerichteten, azyklischen Graphen (directed acyclic graph, DAG) bilden. Beigefügte HTTP-Antwortkopfbereiche werden nicht als Teil des Dokuments betrachtet und sollten vor dem Einfügen in das Dokument entfernt werden. Cachespeicher sollten diese Kopfbereiche aufbewahren, wie sie auch andere Dokumente aufbewahren. Eine alternative Fragment-URI kann angegeben werden. Das vom Attribut ALT angegebene Fragment wird abgerufen und eingefügt, wenn das Fragment des Attributs SRC nicht abgerufen werden kann. Wenn weder das Fragment des Attributs SRC noch das Fragment des Attributs ALT abgerufen werden kann, kann mit der Wiedergabe so fortgefahren werden, als ob kein FRAGMENTLINK-Auszeichnungselement in das ursprüngliche Dokument eingefügt worden wäre.
Die Schwierigkeit bei der Verwendung von dynamischen oder personalisierten Fragmenten besteht darin, dass die URI, die zum Abruf dieser Fragmente verwendet wird, aus der Umgebung oder dem Kontext, in der beziehungsweise in dem sich die Elternseite befindet, berechnet werden sollte. Anders ausgedrückt, die URI muss gegebenenfalls dynamisch aus den Abfrageparametern, die dem Elterndokument beigefügt sind, erzeugt werden; das Attribut PARMS unterstützt diese Funktion. Das Attribut PARMS besteht aus einer Liste mit den Namen der Abfrageparameter von dem Elterndokument, die beim Abruf des Fragments zu verwenden sind. Namen-Wert-Paare werden für jeden auf dem Attribut PARMS bezeichneten Parameter gebildet und als (möglicherweise zusätzliche) Abfrageparameter an die URI angefügt, die im Attribut SRC im FRAGMENTLINK-Auszeichnungselement angegeben ist. Diese Namen-Wert-Paare sollten in derselben Reihenfolge angefügt werden, in der sie auf dem Attribut PARMS erscheinen. Überdies sind gegebenenfalls noch die Cookies erforderlich, die zu dem Elterndokument gehören, um das Fragment korrekt abzurufen oder zu berechnen. Alle Cookies, die dem Elterndokument beigefügt sind, sollten mit der Anforderung für das Fragment geliefert werden.
Bei der Verwendung einer Aktien-Beobachtungsliste beispielsweise werden oftmals viele FRAGMENTLINK-Auszeichnungselemente benötigt, die sich nur im Wert eines Abfrageparameters unterscheiden. Das Attribut FOREACH kann als verkürzte Schreibweise verwendet werden, um die Codierung der Seite zu vereinfachen, die Anforderungen an die Bandbreite bei der Übertragung des Fragments herabzusetzen sowie die Größe des Fragments in einem Cachespeicher zu verringern. Nehmen wir beispielsweise an, dass ein FRAGMENTLINK-Auszeichnungselement wie folgt erzeugt wird:
und nehmen wir weiter an, dass es ein Cookie gibt:
Cookie: issues="stock=IBM stock=CSCO stock=DELL"
Dies würde dazu führen, dass das FRAGMENTLINK-Auszeichnungselement auf eine Reihe von FRAGMENTLINK-Auszeichnungselementen erweitert wird, was wiederum bewirkt, dass jedes neu erzeugte FRAGMENTLINK-Auszeichnungselement ausgewertet wird:

{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?stock=IBM"
alt="An error occurred trying to find stockQuote.jsp" /}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?stock=CSCO"
alt="An error occurred trying to find stockQuote.jsp" /}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?stock=DELL"
alt="An error occurred trying to find stockQuote.jsp" /}
Häufig ist der Text eines Fragments nicht sehr umfangreich und kann als Wert eines Cookie aufgenommen werden, was beträchtliche Leistungssteigerungen während der Zusammensetzung einer Seite zum Ergebnis hat. Um dies anzugeben, wird das Schlüsselwort COOKIE in das Protokoll der URI gestellt, zum Beispiel:

{fragmentlink src="cookie://cookiename" /}
Definition eines FRAGMENT-Kopfbereichs
Nun Bezug nehmend auf 4 ist eine formale Definition des Kopfbereichs FRAGMENT gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung angegeben. Eine Ausführungsform der vorliegenden Erfindung kann einen neuartigen HTTP-Kopfbereich und eine Erweiterung des vorhandenen Kopfbereichs "Cache-Control" verwenden. Der Kopfbereich FRAGMENT ist mit der HTTP-Spezifikation "Hypertext Transport Protocol – HTTP/1.1", Request for Comments 2616 (RFC 2616), Internet Engineering Task Force, Juni 1999, die durch Bezugnahme Bestandteil hiervon ist und von der Website der Internet Engineering Task Force unter www.ietf.org abgerufen werden kann, kompatibel.
Alle Informationen in Bezug auf das Objekt als Fragment sind in einem Kopfbereich mit der Bezeichnung FRAGMENT gekapselt. Dieser Kopfbereich dient zur Feststellung, ob der Client, der Server oder ein dazwischengeschalteter Cachespeicher über Funktionen zur Zusammensetzung von Seiten verfügt. Der Kopfbereich legt auch die Regeln für die Bildung einer Cachespeicher-Kennung für Fragmente fest (auf der Grundlage der Abfrageparameter der URI und Cookies, die dem Objekt beigefügt sind). Darüber hinaus gibt der Kopfbereich die Abhängigkeitsbeziehungen von Objekten mit ihren zugrunde liegenden Daten zur Unterstützung von Operationen zum Ungültigmachen, die von einem Hostrechner eingeleitet werden, an. Der Kopfbereich FRAGMENT soll nur verwendet werden, wenn die Anweisung "Cache-Control: fragmentrules" in Kraft ist. Die vollständige Syntax des Kopfbereichs FRAGMENT ist in 4 gezeigt. Die Definitionen der Attribute des Kopfbereichs FRAGMENT werden nachstehend erörtert.

contains-fragments: Dieses Attribut gibt an, dass der Hauptteil der Antwort Fragment-Anweisungen enthält, die von einem Seitenzusammensetzungs-Programm verwendet werden können.
supports-fragments: Dieses Attribut gibt an, dass entweder der ursprüngliche Anforderer oder ein Cachespeicher in dem Datenstrom die Zusammensetzung von Seiten unterstützen. Diese Anweisung kann von jedem Cachespeicher oder Client eingefügt werden, der die Zusammensetzung von Seiten uneingeschränkt unterstützt.
dependencies: Dieses Attribut gibt eine Liste mit Abhängigkeitsnamen an, von denen der Hauptteil der Antwort abhängig ist.
cacheid: Dieses Attribut gibt die Liste der Regeln an, die zur Bildung der Cachespeicher-Kennung für das Objekt verwendet werden sollen. Wenn eine Regel als "URI" angegeben wird, ist die vollständige URI der Antwort als Cachespeicher-Kennung zu verwenden. Wenn die Cachespeicher-Kennung als eine Regel angegeben wird, sind die Regeln auf die Anforderungs-URI anzuwenden, um eine Cachespeicher-Kennung zu bilden, was nachstehend ausführlicher beschrieben wird.

In der bevorzugten Ausführungsform der vorliegenden Erfindung unterscheiden sich die Regeln für die Zwischenspeicherung von Fragmenten von den Regeln für die Zwischenspeicherung von anderen Arten von Objekten, wenn der Cachespeicher die Zusammensetzung von Seiten unterstützt. Deshalb wird der Kopfbereich "Cache-Control" erweitert, um anzugeben, dass die Regeln für die Zwischenspeicherung von Fragmenten gelten. Dies muss mit einer Erweiterung geschehen, um die Anweisung, dass keine Zwischenspeicherung stattfindet, außer Kraft zu setzen. Eine neue Cachespeicher-Anforderungs-Anweisung mit der Bezeichnung "fragmentrules" wird als Erweiterung des Feldes für den allgemeinen Kopfbereich "Cache-Control" ausgeführt, wie im Abschnitt 14.9.6 der HTTP/1.1-Spezifikation angegeben ist. Mit dieser Erweiterung soll das Verhalten der Anweisung, dass keine Zwischenspeicherung stattfindet, in Cachespeichern, die die Zusammensetzung von Fragmenten unterstützen, geändert werden. Cachespeicher, die keine Zusammensetzung von Fragmenten unterstützen, sollen die Anweisung "fragmentrules" ignorieren, wobei dies das grundlegende Standardverhalten bei HTTP/1.0 und HTTP/1.1 ist. Cachespeicher, die eine Zusammensetzung von Fragmenten unterstützen, sollen die Anweisung "no-cache" ("keine Zwischenspeicherung") (und jedweden Kopfbereich "Pragma: no-cache", sofern vorhanden) ignorieren, wenn diese mit einer Anweisung "fragmentrules" einhergeht, und Zwischenspeicherungs-Regeln gemäß anderen Kopfbereichen, die der Antwort beigefügt sind, anwenden. Ein Beispiel für einen Kopfbereich "Cache-Control" wäre:

Cache-Control: no-cache, fragmentrules
Feststellen von Fähigkeiten und Verantwortlichkeiten bei der Zusammensetzung von Seiten
Die bevorzugte Ausführungsform der vorliegenden Erfindung hat den Vorteil, dass sie in der Lage ist, die Aufnahme von Fragmenten anzugeben, so dass es möglich ist, an jedem Punkt in der Ereigniskette vom Verfassen einer Seite bis hin zu ihrer Darstellung mit dem Browser eine Seitenzusammensetzung durchzuführen, wobei alle Cachespeicher eingeschlossen sind, in denen gegebenenfalls ein Fragment vorhanden ist, einschließlich des Browser-Cachespeichers. Eine Software-Einheit, die eine Seitenzusammensetzung durchführen kann, wird als Seitenzusammensetzungspunkt bezeichnet.
Bei diesem Merkmal sind die folgenden Szenarien möglich:

1. Es gibt keinen Zusammensetzungspunkt, der sich näher am Browser befindet, als der HTTP-Server, der die Seite bereitstellt. In diesem Fall sollte der Server die Zusammensetzung selbst vornehmen und eine vollständig zusammengesetzte Seite bereitstellen.
2. Es gibt einen Proxy irgendeiner Art, der die Seitenzusammensetzung für den ursprünglichen Server durchführen kann. Dieser Proxy kann ein Zusammensetzungspunkt für die Website werden. Der ursprüngliche Server kann diesem Proxy Fragmente bereitstellen und braucht gegebenenfalls keine Seitenzusammensetzung durchzuführen.
3. Der Browser des Benutzers kann eine Seitenzusammensetzung durchführen. In diesem Fall braucht weder ein Netzwerk-Cachespeicher noch ein Netzwerk-Server eine Seitenzusammensetzung vorzunehmen.

Um festzustellen, wie ein Fragment bereitzustellen ist, d. h. vollständig zusammengesetzt oder nicht zusammengesetzt, sollten Server und Cachespeicher herausfinden können, ob wenigstens einer der vorgelagerten Agenten (upstream agents) die Funktion eines Zusammensetzungspunktes hat. Die bevorzugte Ausführungsform der vorliegenden Erfindung verwendet einen HTTP-Anforderungs-Kopfbereich, so dass jeder Agent, der als Zusammensetzungspunkt für den Server dienen kann, den Kopfbereich verwenden kann, um anzugeben, dass er Fragmente annehmen kann und keine vollständige Seite zu empfangen braucht. Die Anweisung "supports-fragments" des Kopfbereichs FRAGMENT kann von jedem Client oder Cachespeicher eingefügt werden, um nachgelagerten Cachespeichern anzuzeigen, dass er ein Zusammensetzungspunkt ist. Ein Beispiel für eine Anweisung "supports-fragments" wäre:

fragment: supports-fragments
Nur weil ein Prozessor die Seitenzusammensetzung unterstützt, bedeutet dies nicht, dass er eine Seitenzusammensetzung an allen Objekten, die er vom Server empfangen hat, durchführen soll. Es stellt sowohl eine Verschwendung von Ressourcen als auch eine mögliche Ursache von Problemen dar, jedes von einem Server empfangene Dokument zu zerlegen und zu versuchen, es zusammenzusetzen. Daher sollte ein Server angeben, dass ein Objekt zusammengesetzt werden muss, bevor es bereitgestellt wird. Die Anweisung "contains-fragments" des Kopfbereichs FRAGMENT sollte von jedem Server eingefügt werden, bei dem eine Seitenzusammensetzung in Cachespeichern oder Browsern erforderlich ist. Ein Beispiel für die Anweisung "contains-fragments" wäre:

fragment: Contains-Fragments
Die meisten marktgängigen HTTP-Cachespeicher, einschließlich der Browser-Cachespeicher, gehen davon aus, dass alle Objekte, die über Abfrageparameter verfügen, nicht zwischengespeichert werden können. HTTP/1.1 erweitert und verallgemeinert die Zwischenspeicherungsfunktionen, um Cachespeichern zu ermöglichen, jedes Objekt, das sie erfolgreich abgerufen haben, zwischenzuspeichern. Selbst HTTP-1.1-Cachespeicher werden jedoch oftmals so konfiguriert, dass sie keine Objekte zwischenspeichern, die sie für dynamisch halten, weil sie annehmen, dass die Zwischenspeicherung von dynamischen Objekten eine schlechte Ausnutzung von Ressourcen darstellt. Ein Beispiel für eine Situation, in der diese Annahme ungültig ist, ist der Fall der personalisierten Daten. Personalisierte Seiten werden erzeugt, indem man einer Seite Abfrageparameter oder Cookies zuweist und die Seite dadurch als eine spezielle personalisierte Instanz einer allgemeineren Seite kennzeichnet. Die Tatsache, dass die Seite personalisiert ist, macht sie nicht zwangsläufig zu einer nicht zwischenspeicherungsfähigen Seite. Die Seite kann nur dann nicht zwischengespeichert werden, wenn die Daten, auf der die Seite beruht, äußerst unbeständig sind. Dies gilt insbesondere bei Unternehmensservern, die nur den Webinhalt eines bestimmten Unternehmens zwischenspeichern.
Das Argument, das gewöhnlich gegen die Zwischenspeicherung einer solchen Seite angeführt wird, ist, dass die Wiederverwendung solcher Seiten zu gering ist, als dass sie die Inanspruchnahme von Platz im Cachespeicher rechtfertigen würde. Dieses Argument ist aus mehreren Gründen unzureichend.

1. Die Kosten für ein Dokument, von seiner ersten Erstellung bis zu seiner schließlichen Wiedergabe in einem Browser, sind nur nominal abhängig von der Größe des Dokuments. Wenn das Dokument in irgendeiner Weise "dynamisch" ist, entsteht der größte Teil der Kosten vor allem bei der Erzeugung des Dokuments. Selbst eine sehr geringe Wiederverwendung kann daher zu beträchtlichen Kosteneinsparungen am Server führen.
2. Die Speicherkapazität von Cachespeichern hat deutlich zugenommen und nimmt auch weiterhin stark zu.
3. Die Übernahme der Fragment-Technologie kann die Datenmenge, die zwischengespeichert wird, tatsächlich verringern, indem redundante Instanzen desselben HTML-Inhalts wegfallen.

Bei der Einführung von Fragmenten besteht die Möglichkeit, die Spezifikation von Cachespeicher-Regeln erheblich zu erschweren, insbesondere, wenn Seitenzusammensetzungs-Programme in Cachespeichern erstellt werden müssen. Jedes Fragment einer Seite kann eine andere Cachespeicher-Regel erforderlich machen. Die bevorzugte Ausführungsform der vorliegenden Erfindung verwendet HTTP-Antwort-Kopfbereiche, um die Granularität der Zwischenspeicherungsregeln gegenüber den nach dem Stand der Technik verfügbaren Zwischenspeicherungsregeln zu erhöhen.
Es gibt zwei Faktoren, die sich auf die Zwischenspeicherung auswirken und den eingesetzten Seitenzusammensetzungs-Programmen mitgeteilt werden müssen: (1) die Lebensdauer von Fragmenten; und (2) die ausdrückliche vom Server eingeleitete Ungültigmachung von Objekten. Wenn es keine vom Server eingeleitete Ungültigmachung gibt, können dieselben Mechanismen zur Angabe der Objekt-Lebensdauer in Cachespeichern für andere Objekte auf Fragmente angewendet werden. Wenn es wichtig ist, zu verhindern, dass ein Fragment in einem Cachespeicher zwischengespeichert wird, der nicht ausdrücklich die Zwischenspeicherung von Fragmenten unterstützt, sollte der Kopfbereich "Cache-Control" mit den Anweisungen "no-cache" und "fragmentrules" in die Antwort aufgenommen werden. Die Anweisung "no-cache" verhindert die Zwischenspeicherung des Fragments durch Cachespeicher, die keine Zwischenspeicherung von Fragmenten vorsehen, und die Anweisung "fragmentrules" gestattet den Cachespeichern, die eine Zwischenspeicherung von Fragmenten vorsehen, die Anweisung "no-cache" außer Kraft zu setzen.
Vom Server eingeleitete Ungültigmachung
Cachespeicher, die eine vom Server eingeleitete Ungültigmachung unterstützen, können darüber informiert werden, welche Fragmente ungültig gemacht werden sollen, wobei dies ausdrücklich vom Server gesteuert wird. Um die Kompatibilität mit vorhandenen und älteren Cachespeichern, die keine vom Server eingeleitete Ungültigmachung erkennen oder unterstützen, aufrechtzuerhalten, sollte solchen Fragmenten, die vom Server ungültig gemacht werden, der HTTP/1.1-Kopfbereich "Cache-Control" und die Anweisung "no-cache" bereitgestellt werden. Diese Fragmente sollten mit der erweiterten Anweisung "fragmentrules" versehen werden, wenn gewünscht wird, dass ein Cachespeicher die Anweisung "no-cache" außer Kraft setzt und fragmentspezifische Regeln anwendet. Jeder Cachespeicher, der das Verfahren zur Zwischenspeicherung von Fragmenten der bevorzugten Ausführungsform der vorliegenden Erfindung ausführt, sollte auch die Funktionen gemäß den HTTP/1.1-Regeln zur Zwischenspeicherungsfähigkeit ausführen, die in der HTTP/1.1-Spezifikation beschrieben sind.
Ein Fragment, das von einem Server ungültig gemacht wird, kann von mehreren Datenquellen abhängen, und mehrere Fragmente können von denselben Daten abhängen. Es ist äußerst wünschenswert, mehrere Fragmente ungültig machen zu können, indem man alle Fragmente, die auf gemeinsamen Daten beruhen, lokalisiert, indem man dem Cachespeicher eine einzige Aufforderung zum Ungültigmachen sendet. Um dies wirksam durchzuführen, weist der Server einem Fragment eine oder mehrere Kennungen für eine Ungültigmachung zu. Cachespeicher, die eine Zwischenspeicherung von Fragmenten vorsehen, verwenden die Kennungen für eine Ungültigmachung, um eine Sekundär-Indexierung für zwischengespeicherten Elemente zu ermöglichen. Wenn eine Aufforderung zu einer vom Server eingeleiteten Ungültigmachung ankommt, werden alle zwischengespeicherten Elemente, die unter den Kennungen für eine Ungültigmachung indexiert sind, ungültig gemacht. Kennungen für eine Ungültigmachung werden über die Anweisung "dependencies" des Kopfbereichs FRAGMENT angegeben. Ein Beispiel für die Verwendung der Anweisung "dependencies" wäre:
fragment: dependencies="dep1 dep2"
Server, die diese Funktion ausführen, verwenden die Anweisung "dependencies", um anzugeben, dass der Service-Hostrechner das Objekt ganz bestimmt ungültig machen wird. Die normale Alterung und die Zwischenspeicherungsfähigkeit gemäß der Definition in der HTTP/1.1 Spezifikation sind von dieser Anweisung nicht betroffen, so dass Objekte, die selten ungültig gemacht werden, aus dem Cachespeicher entfernt werden können, wenn es keine vom Server eingeleitete Ungültigmachung gibt. Wenn der Kopfbereich "dependencies" angegeben wird, können Cachespeicher Kopfbereiche "cache-control: no-cache" ignorieren.
Die Kennung für eine Ungültigmachung, die URI und die Cachespeicher-Kennung haben unterschiedliche Aufgaben. Das Vorsehen von getrennten Mechanismen, um jede dieser Kennungen anzugeben, verhindert unnötige Konflikte bei der Ausgestaltung der Anwendung, die gegebenenfalls schwierig zu lösen wären.
Cachespeicher-Kennungen für dynamische Fragmente
Es ist möglich, ein Objekt unter einer Kennung zwischenzuspeichern, die sich von seiner URI unterscheidet. Es ist auch möglich, auf der Grundlage des Inhalts der URI selbst die genaue Art und Weise, in der die Cachespeicher-Kennung gebildet wird, Einschränkungen zu unterwerfen. Der Grund dafür ist, dass eine URI häufig für ein dynamisches Objekt mit Abfrageparametern gebildet wird, die nicht als Teil der eindeutigen Cachespeicher-Kennung verwendet werden sollten. Wenn diese Parameter nicht vor der Zwischenspeicherung aus der URI entfernt werden, können missglückte Cachespeicher-Zugriffe (cache misses) auftreten, was dazu führt, dass mehrere Kopien desselben Objekts unter mehreren Kennungen gespeichert werden.
Um dieses Problem zu vermeiden, sollte ein Satz von Regeln zur Bildung von Cachespeicher-Kennungen im Antwort-Kopfbereich von dynamischen Objekten mitgeführt werden, deren URI nicht direkt als Cachespeicher-Kennung verwendet werden kann. Jede Regel umfasst eine Liste mit Namen von Abfrageparametern und Namen von Cookies. Nach dem Stand der Technik werden Cookies nicht als Teil einer Cachespeicher-Kennung verwendet, aber bei vielen Anwendungen sind die Daten, die sich in den Cookies befinden, die Informationen, die eine Anforderung so eindeutig von anderen Anforderungen unterscheidet. Der Wert eines Cookie kann daher als Teil einer Cachespeicher-Kennung angegeben werden. Jedes Cookie, das als Teil einer Cachespeicher-Kennung verwendet werden soll, sollte in Form eines Namen-Wert-Paares vorliegen.
Anders ausgedrückt, eine Anweisung CACHEID besteht aus einem oder mehreren Regelsätzen (rulesets). Ein Regelsatz besteht aus einer oder mehreren Regeln. Eine Regel besteht aus einer Liste mit Zeichenketten, wobei jede Zeichenkette der Name eines Abfrageparameters von der Anforderungs-URI oder einem beigefügten Cookie ist. Ein Beispiel für eine Anweisung CACHEID wäre:

fragment: cacheid ="(p1 [p2], c4) (p3, c4 [c5]) URI"
Diese Anweisung besteht aus drei Regeln: (p1 [p2], c4); (p3, c4 [c5]); und der URI. Die Bezeichnungen "p_" in den Regeln sind Parameternamen (parmnames) für Abfrageparameter, und die Bezeichnungen "c_" sind Cookie-Namen (cookienames) für Cookies.
Um eine Cachespeicher-Kennung zu erzeugen, beginnt der Cachespeicher mit dem Pfadnamen-Teil der URI des Fragments. Dann versucht er, jede Regel in einer Regelliste (rulelist) anzuwenden. Wenn jede Regel in einer Regelliste angewendet werden kann, wird die Zeichenkette dieser Aktion als die Cachespeicher-Kennung verwendet. Wenn eine Regel einer Regelliste nicht angewendet werden kann, wird die Regelliste übergangen, die nächste Regelliste wird angewendet und so weiter. Wenn es keine Regelliste gibt, bei der jede nicht optionale Regel angewendet werden kann, kann das Objekt nicht zwischengespeichert werden; andernfalls wird der erste Regelsatz, der erfolgreich angewendet worden ist, zur Bildung der Cachespeicher-Kennung verwendet.
Eine in eckige Klammern eingeschlossene Regel ("[" und "]") ist eine optionale Regel, die, wenn möglich, angewendet werden sollte, aber das Versagen einer optionalen Regel trägt nicht dazu bei, dass die Regelliste versagt. Wenn einem Objekt keine Anweisung CACHEID beigefügt ist, wird das Objekt unter seiner vollständigen URI einschließlich der Abfrageparameter der URI zwischengespeichert.
Um die Regeln anzuwenden, sollte der Cachespeicher zuerst eine Cachespeicher-Basiskennung bilden, indem alle Abfrageparameter aus der ursprünglichen URI entfernt werden. Um eine Parameterregel (parmrule) anzuwenden, sucht der Cachespeicher nach einem Abfrageparameter, bei dem der Name im Parameter parmname angegeben ist. Wenn der Name vorhanden ist, wird das entsprechende Namen-Wert-Paar aus der ursprünglichen URI an die Cachespeicher-Basiskennung angefügt, um eine neue Cachespeicher-Basiskennung zu bilden. Dieser Prozess wird fortgesetzt, bis alle Regeln erfolgreich angewendet worden sind. Wenn eine nicht optionale Regel nicht angewendet werden kann, wird die Cachespeicher-Basiskennung wieder in ihren ursprünglichen Zustand zurückgesetzt, und die nächste Regelliste wird angewendet. Um eine Cookie-Regel (cookierule) anzuwenden, sucht der Cachespeicher nach einem Cookie in Form von einem Namen-Wert-Paar, bei dem der Name im Parameter cookiename angegeben ist. Sofern vorhanden, wird das Namen-Wert-Paar an die Cachespeicher-Basiskennung angefügt, um eine neue Cachespeicher-Basiskennung zu bilden. Dieser Prozess wird fortgesetzt, bis alle Regeln erfolgreich angewendet worden sind. Wenn eine nicht optionale Regel nicht angewendet werden kann, wird die Cachespeicher-Basiskennung in ihren ursprünglichen Zustand zurückgesetzt, und die nächste Regelliste wird angewendet. Wenn eine Regelliste aus der Zeichenkette "URI" besteht, wird die gesamte URI der Antwort als Cachespeicher-Kennung verwendet. In dem vorstehend erwähnten Beispiel wird die vollständige URI der Anforderung verwendet, wenn keine der beiden anderen Regellisten erfolgreich angewendet werden kann.
Wenn eine Anforderung für ein Objekt an einem Cachespeicher ankommt, führt der Cachespeicher, d. h. die Cachespeicher-Verwaltungseinheit oder der Verwalter des Cachespeichers, zuerst eine Prüfung durch, um festzustellen, ob das Objekt unter seiner vollständigen URI zwischengespeichert ist. Wenn ja, wird das Objekt zurückgegeben; wenn nicht, werden aus dem Pfad-Teil der URI des Fragments eine Cachespeicher-Basiskennung gebildet und erneut eine Suche durchgeführt. Wenn das Objekt nicht gefunden wird, wird die zum Cachespeicher gehörende Regel-Tabelle nach der Cachespeicher-Basiskennung durchsucht. Wenn die Cachespeicher-Basiskennung in der Regel-Tabelle des Cachespeichers eingetragen ist, werden die Regeln für diese URI angewendet, wie vorstehend beschrieben wurde. Bei erfolgreicher Anwendung einer Regelliste wird unter der neuen Cachespeicher-Kennung erneut nach dem Objekt gesucht. Wenn es nicht gefunden wird, betrachtet der Cachespeicher dies als einen missglückten Cachespeicher-Zugriff, und die Anforderung wird an den Server weitergeleitet; andernfalls, wenn das Objekt gefunden wird, wird es an den Anforderer zurückgeschickt.
Mit dem vorstehenden Beispiel fortfahrend nehmen wir an, dass die vollständige URI eines Objekts

http://foo.bar.com/buyme?p1=parm1&p3=parm3

lautet und dass der Antwort ein Cookie mit der Bezeichnung "c4" und dem Wert "cookie4" beigefügt ist. In diesem Fall könnte die Cachespeicher-Kennung wie folgt gebildet werden:

http://foo.bar.com/buyme?p1=parm1&p3=parm3

da die erste Regel angewendet wird, d. h. "(p1 [p2], c4)".
Seitenzusammensetzung über mehrere Cachespeicher
Nun Bezug nehmend auf die 5A bis 5G ist eine Gruppe von Agenten, die Fragmente unterstützen, und Agenten, die keine Fragmente unterstützen, auf Objektabruf-Pfaden gezeigt, wobei sie als Grundlage für eine Erörterung der Art und Weise dienen, in der das Verfahren zur Zwischenspeicherung von Fragmenten der bevorzugten Ausführungsform der vorliegenden Erfindung in vielen verschiedenen Verarbeitungsumgebungen erfolgreich ausgeführt werden kann.
Schwierigkeiten können auftreten, wenn es auf dem Pfad zwischen einem Client-Browser und einem Server mehrere Cachespeicher gibt und ein Teil der Cachespeicher Unterstützung für eine Seitenzusammensetzung beansprucht und ein Teil der Cachespeicher dies nicht tut. Diese Probleme treten bei anderen Arten von eingebetteten Objekten wie zum Beispiel bei Bildern oder Multimedia-Objekten nicht auf, da Cachespeicher und Browser diese Objekte immer als unabhängige, nicht zusammengehörende Objekte behandeln. Selbst nach der Darstellung in einem Browser sind die ursprünglichen Objekte im Cachespeicher des Browser immer noch nicht zusammenhängende Objekte. Wenn eine Seite jedoch ein Fragment "p" der obersten Ebene und ein Kindfragment "c" umfasst, kann eine Anforderung für ein Objekt mittels der URI für "p" entweder das Fragment "p" oder die vollständig zusammengesetzte Seite "P" zurückliefern, was davon abhängt, in welchem Maß die Seitenzusammensetzung in der Kette der Agenten unterstützt wird, welche mit dem Browser beginnt und am Zielserver endet.
Die 5A bis 5G zeigen verschiedene Konfigurationen von Agenten mit unterschiedlichen Fähigkeiten sowie die Art und Weise, in der die bevorzugte Ausführungsform der vorliegenden Erfindung sie handhaben kann. In jeder Figur befinden sich ein erster Cachespeicher, Cache1, und ein zweiter Cachespeicher, Cache2, zwischen einem Client-Browser und einem Server. In diesen Beispielen bezeichnet "f" einen Agenten, der Fragmente unterstütz; "nf" bezeichnet einen Agenten, der keine Fragmente unterstützt; "p" bezeichnet ein Elternfragment; "c" bezeichnet ein Kindfragment; und "P(p, c)" bezeichnet die Seite, die zusammengesetzt wird, indem das Kindfragment "c" in das Elternfragment "p" eingebettet wird.
5A stellt den einfachsten Fall dar. In diesem Beispiel unterstützt der Server Fragmente, und die beiden Cachespeicher und der Browser können Fragmente unterstützen, müssen aber nicht zwingend Fragmente unterstützen. Es gibt ein Fragment "p" der obersten Ebene, das ein Kindfragment "c" enthält. Der Server speichert "p" und "c" getrennt, weiß aber, dass sie zusammengehören. Bei einer bestimmten Anforderung für "p" werden, wenn irgendein Agent zwischen dem Browser und dem Server (bei einer beliebigen Anzahl von Ebenen) Fragmente unterstützt, getrennte Fragmente zurückgeschickt; andernfalls setzt der Server die Fragmente zusammen und schickt eine vollständig zusammengesetzte Seite zurück.
Bezug nehmend auf 5B unterstützt der Browser Fragmente, aber der Cache1 und der Cache2 unterstützen keine Fragmente.
Nachdem der Browser "p" angefordert hat (und anschließend "c", nachdem er versucht hat, "p" zusammenzusetzen), hat jeder Agent eine Kopie von "p" und "c" zwischengespeichert. Der Server hat getrennte Fragmente zurückgeschickt, da der Browser angegeben hatte, dass er Fragmente unterstützt. Cache1 und Cache2 verhalten sich jedoch so, als würden sie zwei unabhängige HTTP-Objekte zwischenspeichern, insbesondere, weil sie vom Browser einzeln dazu aufgefordert wurden, aber dennoch wissen der Browser und der Server, dass die Kopien von "p" und "c" zusammengehören. Der Browser speichert sie getrennt zwischen, setzt sie aber zusammen, wenn sie benötigt werden.
Bezug nehmend auf 5C unterstützt der Browser keine Fragmente, aber der Cache1 und der Cache2 unterstützen Fragmente. In diesem Fall hat der Server getrennte Fragmente zurückgeschickt, da der Cache2 angegeben hatte, dass er Fragmente unterstützt. Der Cache2 hat getrennte Fragmente zurückgeschickt, da Cache1 angegeben hatte, dass er Fragmente unterstützt. Der Cache1 hat die letzte Seite "P(p, c)" aus den Fragmenten "p" und "c" zusammengesetzt, bevor er sie an den Browser zurückgeschickt hat, da der Browser keine Unterstützung von Fragmenten angegeben hatte.
Bezug nehmend auf 5D unterstützen der Browser und der Cache2 keine Fragmente, aber der Cache1 unterstützt Fragmente. Der Server hat getrennte Fragmente zurückgeschickt, da der Cache1 eine Unterstützung von Fragmenten angegeben hatte, und diese Angabe wurde im HTTP-Kopfbereich durch den Cache2 übertragen. Der Cache2 verhält sich so, als würde er zwei unabhängige HTTP-Objekte zwischenspeichern, aber der Browser, der Cache1 und der Server wissen, dass die getrennten Fragmente zusammengehören. Der Cache2 hat getrennte Fragmente weitergereicht, da sie getrennt zwischengespeichert wurden und er nicht wusste, dass sie zusammengehören. Der Cache1 hat die letzte Seite "P(p, c)" aus den Fragmenten "p" und "c" zusammengesetzt, bevor er sie an den Browser zurückgeschickt hat, da der Browser keine Unterstützung von Fragmenten angegeben hatte.
Bezug nehmend auf 5E unterstützen der Browser und der Cache1 keine Fragmente, aber der Cache2 unterstützt Fragmente. Der Server hat getrennte Fragmente zurückgeschickt, da der Cache2 angegeben hatte, dass er Fragmente unterstützt. Der Cache2 hat die letzte Seite "P(p, c)" aus den Fragmenten "p" und "c" zusammengesetzt, bevor er sie an den Cache1 weitergereicht hat, da weder der Browser noch der Cache1 eine Unterstützung von Fragmenten angegeben hatte. Der Cache1 und der Browser speichern die zusammengesetzten Fragmente als ein einzelnes HTTP-Objekt, d. h. als die letzte Seite "P(p, c)".
Bezug nehmend auf 5F wird der einzelne Browser durch zwei Browser ersetzt, den Browser1 und den Browser2. Der Browser2 gibt eine Anforderung für eine Seite aus, die sich auf das Elternfragment "p" abbilden lässt. Der Cache1 leitet eine Anforderung an den Cache2 weiter, die den vom Browser2 ausgegebenen Kopfbereich "supports-fragments" mitführt. Der Cache2 schickt das Fragment "p" mit einer Fragment-Verknüpfung für das Fragment "c" an den Cache1 zurück; der Cache1 schickt es an den Browser2 zurück. Der Browser2 zerlegt das Fragment "p" und gibt dann eine Anforderung für das Kindfragment "c" aus.
Ein mögliches Problem tritt auf, wenn der Browser1, der nicht für eine Verarbeitung von Fragmenten konfiguriert ist, nun eine Anforderung für die Seite ausgibt. Der Browser1 gibt eine Anforderung aus, die eine URI enthält, bei der es sich um die gleiche URI handelt, die auch vom Browser2 ausgegeben wurde, und diese URI stimmt mit der Cachespeicher-Kennung für das Fragment "p" überein. Wenn das Fragment "p" im Cache1 zwischengespeichert wurde, sendet der Cache1 das zwischengespeicherte Fragment, welches das Auszeichnungselement FRAGMENTLINK für das Fragment "c" enthält, an den Browser1. Da der Browser1 das FRAGMENTLINK-Auszeichnungselement nicht versteht, ignoriert er es, was dazu führt, dass eine unvollständige Seite dargestellt wird.
Diese Situation lässt sich auf jede Konfiguration im Netzwerk verallgemeinern, bei der sowohl ein Agent, der Fragmente unterstützt, als auch ein weiterer Agent, der keine Fragmente unterstützt, mit einem Cachespeicher verbunden sind, der keine Fragmente unterstützt, wie in 5G allgemeiner dargestellt ist. Wenn der Browser2 das Fragment "p" anfordert, empfängt der Cache1, der Fragmente unterstützt, die Fragmente "p" und "c" und setzt sie zusammen, woraufhin der Cache1 dem Browser2 die Seite "P(p, c)" liefert. Eine nachfolgende Anforderung für das Fragment "p" vom Browser1 durch den Cache1 könnte dazu führen, dass eine nicht zusammengesetzte Seite geliefert wird.
Um dieses mögliche Problem zu lösen, sollte jedes Fragment der obersten Ebene von einem Server, der die Zusammensetzung von Seiten unterstützt, die Fragmente der obersten Ebene beispielsweise mittels "Cache-Control: no-cache fragmentrules" als Fragmente kennzeichnen, die nicht zwischengespeichert werden können. Cachespeicher, die eine Seitenzusammensetzung unterstützen, erkennen die "fragmentrules" in der Anweisung, setzen dadurch die Anweisung "no-cache" außer Kraft und wenden das richtige Verhalten auf das Objekt an. Es sei angemerkt, dass nur Fragmente der obersten Ebene als Fragmente gekennzeichnet werden sollten, die nicht zwischengespeichert werden können, um diese Situation zu bewältigen. Der Grund dafür liegt in der mangelnden Eindeutigkeit, die sich ergeben kann, da die URI für die ganze Seite gleich der URI für das Fragment der obersten Ebene ist; d. h., die URI kann sich auf zwei verschiedene Objekte beziehen. Eingebettete Fragmente kommen nur in einer einzigen Form vor, so dass diese Mehrdeutigkeit bei eingebetteten Fragmente nicht vorkommt.
Überlegungen zur Verhinderung einer ungeeigneten Zwischenspeicherung
Wie unmittelbar zuvor erwähnt wurde, sollte jedes Fragment der obersten Ebene von einem Server, der die Zusammensetzung von Seiten unterstützt, die Fragmente der obersten Ebene als Fragmente kennzeichnen, die nicht zwischengespeichert werden können. Dadurch wird ein mögliches Problem verhindert, bei dem ein Cachespeicher, der keine Fragmente unterstützt, versucht, ein Fragment der obersten Ebene zwischenzuspeichern, das andere Fragmente enthält; wenn er dies täte, wie in 5G gezeigt ist, könnte ein Browser, der keinen Cachespeicher enthält, welcher Fragmente unterstützt, auf das Fragment der obersten Ebene auf irgendeinem Pfad zugreifen, wodurch die Seite statt mit dem Inhalt, der von den FRAGMENTLINK-Auszeichnungselementen angegeben wird, nicht ordnungsgemäß mit FRAGMENTLINK-Auszeichnungselementen dargestellt würde.
Darüber hinaus würde ein Cachespeicher, der keine Fragmente unterstützt, üblicherweise die URI oder den URI-Pfad, die beziehungsweise der zu einem Objekt gehört, als Cachespeicher- Index/-Schlüssel verwenden; ohne Wissen des Cachespeichers könnte das Objekt ein Fragment sein. Da das Objekt ein Fragment ist, ist es möglicherweise nicht sinnvoll, nur die URI oder den URI-Pfad als Cachespeicher-Kennung in demjenigen Cachespeicher zu verwenden, der keine Fragmente unterstützt; in einem Cachespeicher, der Fragmente unterstützt, würde eine Cachespeicher-Kennung entsprechend den Regeln für die Zwischenspeicherung von Fragmenten, die zu dem Objekt, d. h. dem Fragment, gehören, gebildet werden. Anders ausgedrückt, der Cachespeicher, der keine Fragmente unterstützt, formuliert weiterhin seine Cachespeicher-Indizes entsprechend seinem Algorithmus für Cachespeicher-Kennungen für alle zwischengespeicherten Objekte, aber dennoch beabsichtigt das Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung, dass die Regeln für die Zwischenspeicherung von Fragmenten zur Bildung von Cachespeicher-Kennungen für zwischenspeicherbare Fragmente angewendet werden, bevor ein Cachespeicher-Index erzeugt wird, um das Fragment im Cachespeicher abzulegen. Daher könnte der Cachespeicher, der keine Fragmente unterstützt, sein Objekt, bei dem es sich eigentlich um ein Fragment handelt, als Folge eines Cache-Treffers möglicherweise in einer Antwort zurückschicken. Verschiedene Arten von Ungenauigkeiten oder Fehlern bei der Wiedergabe könnten dann stromabwärts auftreten. Um solche Fehler zu vermeiden, sollte eine Zwischenspeicherung gegebenenfalls verhindert werden.
Im Allgemeinen kann die Zwischenspeicherung in Cachespeichern, die keine Fragmente unterstützen, verhindert werden, indem man den Kopfbereich "Cache-Control: no-cache fragmentrules" und den Kopfbereich "Pragma: no-cache" aufnimmt. Der zweite Kopfbereich weist Cachespeicher, die HTTP/1.1 nicht unterstützen, an, das Fragment nicht zwischenzuspeichern; ein Cachespeicher, der Fragmente unterstützt, sollte auch HTTP/1.1 unterstützen. Wie vorstehend mit Bezug auf 5G kurz erwähnt wurde, teilt die Anweisung "no-cache" in dem ersten Kopfbereich Cachespeichern, die HTTP/1.1, aber keine Fragmente unterstützen, mit, das Fragment nicht zwischenzuspeichern, und die Anweisung "fragmentrules" teilt Cachespeichern, die Fragmente unterstützen, mit, dass das Fragment gemäß den Regeln für die Zwischenspeicherung von Fragmenten zwischengespeichert werden soll.
Überlegungen hinsichtlich einer wirksamen Zwischenspeicherung
Bei Fragmenten, die von mehreren Benutzern gemeinsam benutzt werden, z. B. eine Produktbeschreibung oder ein Aktienkurs, ist es sinnvoller, eine Zwischenspeicherung in den meisten oder in allen Cachespeichern zwischen dem Browser und dem Web-Anwendungs-Server zuzulassen. Fragmente können als in einer Baumstruktur verteilte Fragmente betrachtet werden, wobei jeder Cachespeicher zu anderen Cachespeichern verzweigt. Die erste Anforderung für ein bestimmtes Fragment versieht Cachespeicher auf dem Pfad zwischen dem Benutzer und dem Web-Anwendungs-Server mit Einträgen. Bei nachfolgenden von anderen Benutzern gestellten Anforderungen für dasselbe Fragment besteht die Möglichkeit, dass das Fragment in diesen Cachespeichern gefunden wird, ohne dass man bis zum Web-Anwendungs-Server vordringen muss.
Bei Fragmenten, die benutzerspezifisch sind, z. B. bei personalisierten Fragmenten wie einer Aktien-Beobachtungsliste, ist es am sinnvollsten, wenn man eine Zwischenspeicherung nur in dem Cachespeicher, der Fragmente unterstützt und der sich in nächster Nähe des Endbenutzers befindet, zulässt, da die einzigen nachfolgenden Anforderungen für dasselbe Fragment auf demselben Pfad ausgegeben werden. Andernfalls füllen sich die dazwischengeschalteten Cachespeicher mit diesen benutzerspezifischen Fragmenten, obgleich diese dazwischengeschalteten Cachespeicher nie eine nachfolgende Anforderung für diese benutzerspezifischen Fragmente zu sehen bekommen, da solche Anforderungen von Cachespeichern erfüllt werden, die sich viel näher am Benutzer befinden, wodurch gemeinsam benutzte Fragmente aus den dazwischengeschalteten Cachespeichern herausgedrängt werden.
Der HTTP-Kopfbereich "Cache-Control" mit der Anweisung "private" wurde zuvor verwendet, um das gleiche benutzerspezifische Merkmal für Seiten anzugeben, so dass nur Cachespeicher von Browsern sie zwischenspeichern. Derselbe Kopfbereich wird von der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet, um Cachespeicher, die Fragmente unterstützen, anzuweisen, Inhalte in dem Cachespeicher zwischenzuspeichern, der Fragmente unterstützt und der sich in nächster Nähe des Benutzers befindet. Es sei angemerkt, dass die Aufnahme von "Cache-Control: private" in ein benutzerspezifisches Fragment eine optionale Leistungsoptimierung darstellt.
Überlegungen bei Verbunddokumenten
Beim Abruf von Fragmenten zur Fragment-Zusammensetzung sollte eine HTTP-Anforderung gebildet werden. Die meisten Kopfbereiche für diese Antwort können von den Antwort-Kopfbereichen in dem Fragment der obersten Ebene geerbt werden. Manche Antwort-Kopfbereiche beziehen sich jedoch auf das jeweilige Objekt, das abgerufen wird, und wenn sie von einem Elternfragment geerbt werden, sollte sorgfältig mit ihnen umgegangen werden. Ebenso können die meisten Antwort-Kopfbereiche verworfen werden, und die Antwort-Kopfbereiche, die dem Fragment der obersten Ebene beigefügt sind, können verwendet werden, wenn die Antwort an den Client zurückgeschickt wird. Wiederum sind manche Antwort-Kopfbereiche objektspezifisch und können sich auf den Zustand des gesamten Dokuments auswirken.
In diesem Abschnitt werden die Fragen hinsichtlich der Verarbeitung der HTTP-Anforderungs-/Antwort-Kopfbereiche bei der Zusammensetzung von Fragmenten erörtert. Der Begriff "abwärtsgerichtete Weitergabe" ("downward propagation") wird verwendet, um darauf zu verweisen, dass eine Anforderung für ein eingebettetes Objekt Anforderungs-Kopfbereiche vom Elternfragment oder von dem Fragment der obersten Ebene erbt. Der Begriff "aufwärtsgerichtete Weitergabe" ("downward propagation") wird verwendet, um darauf zu verweisen, dass Antwort-Kopfbereiche von einem eingebetteten Objekt in dem Elternfragment oder in dem Fragment der obersten Ebene aufgelöst werden.
Ein spezielles Problem, das Verbunddokumente in Bezug auf Cookies betrifft, besteht darin, dass der ursprüngliche Antwort-Kopfbereich "set-cookie" während der Zusammensetzung der Seite nicht zur Verfügung steht. Nur der sich ergebende Cookie-Anforderungs-Kopfbereich ist vom Client verfügbar. Insbesondere sind keine der jeweiligen "path"-, "domain"- oder "expires"-Werte verfügbar. Wenn ein weniger stark verschachteltes Fragment ein anderes Fragment einbettet, das nicht die Einschränkungen erfüllt, die dem Cookie auferlegt wurden, das mit der Anforderung eintraf, ist eine Weitergabe dieses Cookie an das Kindfragment nicht korrekt. Da nicht alle ursprünglichen Informationen vorhanden sind, ist es im Allgemeinen nicht möglich, festzustellen, ob die Weitergabe des Cookie in Ordnung ist. Ebenso kann ein verschachteltes Fragment einen beigefügten Kopfbereich "set-cookie" haben. Gegebenenfalls benötigt man den tatsächlichen Wert dieses Cookie, um die Cachespeicher-Kennung dieses Fragments zu berechnen. Darüber hinaus braucht man möglicherweise den Wert des Cookie, um stärker verschachtelte Fragmente abzurufen. Einige Informationen können jedoch abgeleitet werden. Man kann annehmen, dass der Teil "expires" des Cookie noch nicht in Kraft getreten ist; wenn er in Kraft getreten wäre, wäre das Cookie nicht in der Anforderung vorhanden. Man kann auch annehmen, dass die Domäne ein Teil der Domäne in der Anforderung ist, und man kann überdies annehmen, dass der Pfad ein Teil des Pfades in der Anforderung ist.
Normalerweise prüft ein Browser die einem Cookie auferlegten Einschränkungen, und wenn eine Anforderung die Einschränkungen nicht erfüllt, wird das Cookie nicht in die Kopfbereiche der Anforderung aufgenommen. In einem Cachespeicher, der eine Seite zusammensetzt, ist es jedoch möglich, dass ein FRAGMENTLINK-Auszeichnungselement, das mit einem beigefügten Cookie in einem Dokument enthalten ist, auf eine URI verweist, die nicht die Einschränkungen des ursprünglichen Cookie erfüllt. Da das Objekt, auf das im FRAGMENTLINK-Auszeichnungselement verwiesen wurde, gegebenenfalls das Cookie des Elternteils erforderlich macht, um korrekt ausgewertet zu werden, sollten Cookies von weniger stark verschachtelten Fragmenten an stärker verschachtelte Fragmente weitergegeben werden. Um sicherzustellen, dass das Seitenzusammensetzungs-Programm ein Cookie nicht in einer inkorrekten Weise weiterreicht, welche die Einschränkungen, denen dieses Cookie unterliegt, verletzt, lautet die Richtlinie, dass der Pfad und die Domäne für die URI des verschachtelten Fragments dem konservativsten Teil des Pfades und der Domäne des Fragments der obersten Ebene entsprechen sollten. Anders ausgedrückt, die Domäne in der URI des verschachtelten Fragments sollte der Domäne der Eltern-URI entsprechen oder eine Obermenge davon sein, und der Pfadteil der URI sollte dem Pfad der Eltern-URI entsprechen oder eine Obermenge davon sein. Dies kann als "abwärtsgerichtete Weitergabe von Cookies" ("downward propagation of cookies") bezeichnet werden.
Im Gegensatz dazu beschreibt das Folgende die "aufwärtsgerichtete Weitergabe von Cookies" ("upward propagation of cookies"). Wenn ein Fragment von einem Hostrechner abgerufen wird, ist es möglich, dass die Antwort einen Kopfbereich "set-cookie" enthält. Dieses Cookie kann selbst für eine korrekte Auswertung der stärker verschachtelten Fragmente in dem neu zurückgelieferten Fragment erforderlich sein. Daher sollte das Seitenzusammensetzungs-Programm den Kopfbereich "set-cookie" in einen Kopfbereich "cookie" umwandeln, um stärker verschachtelte Fragmente abzurufen. Dieses neue Cookie kann aus mindestens zwei Gründen erforderlich sein: (1) zur Auswertung von stärker verschachtelten Fragmenten am Server; und (2) zur Erzeugung der Cachespeicher-Kennung für das kürzlich abgerufene Fragment oder für die stärker verschachtelten Fragmente. In dem Fall, dass das Cookie zur Erzeugung einer Cachespeicher-Kennung benötigt wird, muss das neue Cookie mit der zusammengesetzten Seite an den Anforderer zurückübertragen werden. Der Grund dafür ist, dass das Cookie der nächsten Anforderung für diese Seite oder für irgendeine andere Seite, die auf das zwischengespeicherte Fragment verweist, beigefügt werden sollte, um die Cachespeicher-Kennung anhand der Anforderung zu berechnen, bevor versucht wird, sie vom Server abzurufen.
Die Umwandlung des im Kopfbereich "set-cookie" befindlichen Cookie in einen Kopfbereich "cookie" in der Anforderung für verschachtelte Fragmente stellt den Vorgang der stillschweigenden Annahme des Cookie im Namen des Benutzers dar. Die Richtlinie zum Umgang mit dieser Situation beinhaltet Folgendes: (1) das Fragment der obersten Ebene sollte bereits ein Cookie mit diesem Namen haben; und (2) der Pfad und die Domäne des Fragments sollten dem konservativsten Teil des Pfades und der Domäne des Fragments der obersten Ebene entsprechen.
Wenn diese Einschränkungen erfüllt werden, wirkt sich der neue Kopfbereich "set-cookie" einfach dahingehend aus, dass der Wert eines vorhandenen Cookie geändert wird. Vom Standpunkt einer Anwendung aus betrachtet, bedeutet dies lediglich, dass dem Fragment der obersten Ebene gegebenenfalls "Pseudo"-Cookies beigefügt werden müssen. Die Werte dieser "Pseudo"-Cookies werden während des Abrufs der verschachtelten Fragmente und zum Zeitpunkt der Rücksendung der Kopfbereiche "set-cookie" des Fragments an den Benutzer aktualisiert.
Eine weitere spezielle Überlegung bei Verbunddokumenten mit Ausnahme von Cookies schließt die Kopfbereiche "if-modified-since" ein. Der Kopfbereich "if-modified-since" wird von Anforderern verwendet, um anzugeben, dass ein Objekt nur zurückgeschickt werden sollte, wenn es seit einem bestimmten Datum und einer bestimmten Uhrzeit geändert worden ist. Wenn das Objekt seit diesem Zeitpunkt nicht geändert worden ist, wird es als "frisch" betrachtet, und normalerweise wird eine HTTP-304-Antwort "Not Modified" ("Nicht geändert") vom Server zurückgeschickt, wodurch die Bandbreite gespart wird, die zur Übertragung des größeren Antwort-Hauptteils erforderlich wäre.
Bei einem Verbunddokument können einige Komponenten "frisch" sein, während andere "veraltet" sind, und der Status von noch anderen Komponenten kann unbestimmt sein. Wenn keine Komponente als "frisch" festgestellt werden kann, sollte das ganze Dokument als vollständige Antwort (HTTP 200) zurückgeschickt werden. Wenn alle Komponenten als "frisch" festgestellt wurden, kann eine HTTP-304-Antwort zurückgeschickt werden. Um festzustellen, ob ein Fragment frisch ist, kann es gegebenenfalls jedoch notwendig sein, eine Seitenzusammensetzung durchzuführen und dabei die HTTP-Antwort-Codes der Komponenten zu beachten. Wenn eine Komponente "frisch" ist, wird ihr Inhalt immer noch benötigt, sofern die Komponente kein Blattknoten ist, um Komponenten zu suchen und abzurufen, die verschachtelt sind.
Daher sollten Anforderungen an den Cachespeicher, bei denen eine HTTP-304-Antwort zurückgeschickt würde, auch den Text des Fragments zurückschicken, so dass mit der Zusammensetzung der Seite fortgefahren werden kann. Anforderungen an den Server, zum Beispiel als Folge eines missglückten Cachespeicher-Zugriffs, sollten ohne den Kopfbereich "if-modified-since" ausgegeben werden, da der Server andernfalls eine HTTP-304-Antwort zurückschicken könnte, wenn der Text des Fragments erforderlich gewesen wäre, um mit der Zusammensetzung der Seite fortzufahren. Anders ausgedrückt, "if-modified-since"-Kopfbereiche können bei Verbunddokumenten nicht in Abwärtsrichtung weitergegeben werden, da eine HTTP-304-Antwort dazu führen könnte, dass eine ungültige Antwort an den Client geschickt wird.
Eine weitere spezielle Überlegung bei Verbunddokumenten ist ähnlich der bei den Kopfbereichen "if-modified-since" angestellten Überlegung, beinhaltet stattdessen aber "last-modified"-Kopfbereiche. Das Seitenzusammensetzungs-Programm sollte auch verstehen, welche Fragmente "last-modified"-Kopfbereiche zurückschicken und die Ergebnisse zu einem kombinierten "last-modified"-Kopfbereich mit dem neuesten Datum für die zusammengesetzte Seite zusammenfassen. Wenn keines der Fragmente einen Kopfbereich "last-modified" zurückschickt, braucht die gesamte zusammengesetzte Seite keinen Kopfbereich "last-modified" zurückschicken. Dies ist wichtig, weil der Browser den Inhalt ignoriert, wenn er bemerkt, dass der Kopfbereich "last-modified" gleich der Datei in seinem lokalen Cachespeicher ist.
Betrachten wir beispielsweise eine Seite, die einen Teil mit dynamischem Inhalt (ohne Kopfbereich "last-modified") und einen Teil mit statischem Inhalt (von HTML) mit einem Kopfbereich "last-modified" enthält. Wenn man die Seite mit dem "last-modfied"-Kopfbereich der statischen Seite zurückschicken müsste, würden nachfolgende Anforderungen für dieselbe Seite vom Browser ignoriert werden, und die alte Seite aus dem Cachespeicher des Browser würde angezeigt werden. Anders ausgedrückt, wenn alle Fragmente einen Kopfbereich "last-modified" enthalten, sollte er in Aufwärtsrichtung übertragen und angepasst werden, um den letzten Änderungszeitpunkt eines Fragments, das Bestandteil ist, widerzuspiegeln. Wenn ein Fragment nicht über einen Kopfbereich "last-modified" verfügt, kann kein "last-modified"-Kopfbereich zurückgeschickt werden.
Überlegungen bei Programmiermodellen
Die bevorzugte Ausführungsform der vorliegenden Erfindung beschreibt ein Verfahren zur verteilten Zwischenspeicherung von Fragmenten. Es ist jedoch beabsichtigt, so neutral wie möglich zu bleiben, so dass jedes Programmiermodell für einen Web-Anwendungs-Server das Verfahren nutzen kann, um Zwischenspeicherungsfunktionen, beispielsweise auf dazwischengeschaltete Server und Browser, zu übertragen. Die bevorzugte Ausführungsform der vorliegenden Erfindung verwendet HTML-Erweiterungen, d. h. das Auszeichnungselement FRAGMENTLINK, und HTTP, d. h. neue Kopfbereiche zur Zwischenspeicherung von Fragmenten, die ebenfalls neutral in Bezug auf das Programmiermodell sind.
Bei der Programmierung von Fragmenten sollte ein Entwickler von Web-Anwendungen die folgenden beiden Arten von Informationen angeben:

1. einen Aufnahmemechanismus (include mechanism). Diese Information gibt an, welches Fragment aufgenommen und an welcher Stelle es innerhalb eines anderen Fragments aufgenommen werden soll. Da seine Position auf der Seite wichtig ist, muss diese in Code eingebettet werden, z. B. in JSP-Schablonen oder Servlet-Klassen.
2. die Zwischenspeicherung von Steuerungs-Metadaten. Diese Information gibt die Bedingungen für ein Fragment an, zum Beispiel die Zeitgrenzen. Diese Information kann entweder in Code eingebettet oder gesondert angegeben werden, indem man sie dem Namen der Schablone zuordnet, beispielsweise einem Namen einer JSP-Datei oder einer Servlet-Klasse.

Wenn das Programmiermodell J2EE zur Umsetzung der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet wird, können diese beiden Merkmale von den folgenden Mechanismen unterstützt werden:

1. Bei dem Aufnahmemechanismus verfügt das J2EE-Programmiermodell bereits über ein Aufnahmekonstrukt, z. B. das Auszeichnungselement "jsp:include" oder die Methode "RequestDispatcher.include" im Web-Anwendungs-Server, um aufgenommene Fragmente anzugeben. Die J2EE-Laufzeit kann geändert werden, um das J2EE-Aufnahmekonstrukt gegebenenfalls in ein Auszeichnungselement FRAGMENTLINK umzuschreiben.
2. Die Informationen zur Steuerung der Zwischenspeicherung können von einer Systemverwaltungskonsole angegeben und jeder Fragment-Schablone/Klasse zugeordnet werden, statt sie in Code einzubetten. Der Web-Anwendungs-Server kann diese Informationen in die entsprechenden Kopfbereiche einfügen. Diese Vorgehensweise hat die folgenden Vorteile gegenüber der Vorgehensweise, bei der diese Informationen in Code eingebettet werden: A. Statt Programmierer einschalten zu müssen, weil die Informationen in Code eingebrannt werden, ermöglicht sie die dynamische Durchführung von Änderungen über eine Verwaltungskonsole. B. Sie verhindert, dass das J2EE-Programmiermodell um neue Mechanismen erweitert werden muss.

Beim Umschreiben eines J2EE-Aufnahmekonstrukts in ein FRAGMENTLINK-Auszeichnungselement müssen folgende Überlegungen angestellt werden. Die J2EE-Semantik für Abfrageparameter besagt, dass alle Abfrageparameter von einem Elternfragment rekursiv an ein Kindfragment übergeben werden. Wenn ein J2EE-Web-Anwendungs-Server ein FRAGMENTLINK-Auszeichnungselement erzeugt, sollte das SRC-Attribut die URI des J2EE-Aufnahmekonstrukts sein, wobei die Abfrageparameter des Elternfragments angefügt werden. Ein Web-Anwendungs-Server, der kein J2EE-Web-Anwendungs-Server ist, würde das SRC-Attribut so erzeugen, dass es seinem Programmiermodell entspricht. Auf diese Weise tritt die gleiche Semantik auf, ungeachtet dessen, ob ein Ersatz vorhanden ist oder nicht, da die vom Anwendungscode wahrgenommene Anforderung in beiden Fällen genau gleich ist. Das FRAGMENTLINK-Auszeichnungselement hat mehrere Attribute, z. B. ALT, FOREACH, SHOWLINK, ID und CLASS, die über kein entsprechendes Attribut "jsp:include" verfügen. Um in einer J2EE-Umgebung verwendet werden zu können, müsste "jsp:include" bei diesen Merkmalen erweitert werden.
Andere Web-Anwendungs-Server können andere Programmiermodelle (z. B. ASP) unterstützen, die über ähnliche, aber dennoch unterschiedliche Mechanismen zur Aufnahme eines verschachtelten Fragments verfügen. Bei jedem dieser Programmiermodelle sollte der Web-Anwendungs-Server FRAGMENTLINK-Auszeichnungselemente erzeugen, die mit den Regeln dieses Programmiermodells vereinbar sind.
Überlegungen hinsichtlich des Ungültigmachens
Um Cachespeicher auf dem neuesten Stand zu halten, müssen Einträge ungültig gemacht oder überschrieben werden, wenn ihr Inhalt nicht mehr gültig ist. Eine Ungültigmachung kann entweder zeitbasiert erfolgen oder durch ein externes Ereignis ausgelöst werden. Die Zeitspanne kann entweder eine höchstmögliche Lebensdauer im Cachespeicher, z. B. eine maximale Lebensdauer von 10 Minuten, oder eine absolute Zeitangabe sein, z. B. nicht später als 12.00 Uhr am 5.2.2001. Die höchstmögliche Lebensdauer wird unter Verwendung des standardmäßigen HTTP-Kopfbereichs "Cache-Control" mit der standardmäßigen HTTP-Anweisung "max-age" angegeben. Die absolute Zeitangabe wird mittels des standardmäßigen HTTP-Kopfbereichs "Expires" angegeben.
Beispielsweise könnte es bei einer Produktbeschreibung akzeptabel sein, dass sie bis zu 10 Minuten veraltet ist. Dies würde als "Cache-Control: max-age=600" angegeben werden, was bedeutet, dass dieses Fragment nicht länger als 600 Sekunden im Cachespeicher verbleiben wird. Als ein weiteres Beispiel könnte ein Verkauf bis Montag, 24.12.2001 um 23.00 Uhr EST dauern. Dies würde als "Expires=Mon, 24 Dec 2001 23:00:00 EST" angegeben werden. In beiden Fällen kann das Fragment über den Ersetzungsalgorithmus des Cachespeichers aus dem Cachespeicher entfernt werden, um Platz für neue Fragmente zu schaffen.
Bei Ungültigmachungen, die durch ein Ereignis ausgelöst werden, leitet der Anwendungs-Server eine Ungültigmachung ein. Der Anwendungs-Server kann Datenbank-Trigger, eine Anwendungsprogrammierschnittstelle (API), die von einer aktualisierenden HTTP-Anforderung aufgerufen wird, oder irgendeinen anderen Mechanismus verwenden, um festzustellen, dass Inhalte inzwischen veraltet sind.
Das Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung ist für viele verschiedene Mechanismen zum Ungültig-machen offen. Ebenso wird das Protokoll, das von einem Anwendungs-Server verwendet wird, um Nachrichten über Ungültigmachung an Cachespeicher, die Fragmente unterstützen, zu senden, von dem Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung nicht zwingend vorgeschrieben.
Die Abhängigkeit eines Fragments ist eine Kennung für zugrunde liegende Daten, die zur Erzeugung des Fragments verwendet wurde. Als ein Beispiel einer Abhängigkeit könnten mehrere Seiten dasselbe zugrunde liegende Nutzerprofil, aber verschiedene Fragmente verwenden, da unterschiedliche Untergruppen des Benutzerprofils verwendet werden oder sie unterschiedlich formatiert sind. Die Anwendung könnte die Zuordnung zwischen dem Benutzerprofil und allen Fragmenten, die es verwenden, feststellen und immer dann die Cachespeicher-Kennung für diese Fragmente erstellen, wenn sich das Benutzerprofil ändert. Eine bessere Software-Technik zeichnet sich jedoch dadurch aus, dass sich diese Zuordnungsfunktion in jedem der Fragmente befindet, das die Quelle einer jeden Abhängigkeit ist. Dies ermöglicht der Anwendung, eine Ungültigmachung einfach mittels der Benutzerkennung durchzuführen, die zu dem Benutzerprofil gehört, und den Cachespeicher zu veranlassen, alle Fragmente ungültig zu machen, die von der Benutzerkennung abhängig sind. Wenn ein neues Fragment hinzugefügt wird, welches das Benutzerprofil verwendet, oder ein Fragment entfernt wird, ist die Abhängigkeit lokal auf dieses Fragment beschränkt, und der Mechanismus der Anwendung zum Ungültigmachen bleibt unverändert. Diese Abhängigkeit könnte für ein bestimmtes Benutzerprofil zum Beispiel in der folgenden Weise erklärt werden:

Fragment:
dependencies="http://www.acmeStore.com_userID=@($*!%"
Mehrere Abhängigkeiten werden als eine durch Leerzeichen getrennte Liste angegeben. Bei Abhängigkeiten wird nach Groß- und Kleinschreibung unterschieden. Ein Cachespeicher, der Fragmente unterstützt, gestattet, dass ungültigmachungen auf der Grundlage dieser Abhängigkeiten stattfinden.
Um eine Vorgehensweise, bei der überschrieben wird, anwenden zu können, um Einträge im Cachespeicher ungültig zu machen, sind keine neuen Kopfbereich-Informationen erforderlich. Der Cachespeicher, der Fragmente unterstützt, benötigt ein Protokoll, das es ermöglicht, neue Einträge in den Cachespeicher hinzuzufügen. Ebenso wie das vorstehend erwähnte Protokoll zum Ungültigmachen wird auch dieses Überschreibungsprotokoll von dem Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung nicht zwingend vorgeschrieben.
Überlegungen hinsichtlich Sicherheitsfragen
Mögliche Anforderungen an die Sicherheit sollten von Cachespeichern, die Fragmente unterstützen, beachtet werden. Wenn ein Benutzer eine browserähnliche Anwendung ausführt und auf eine URI klickt, vertraut er dem Entwickler der Anwendung dahingehend, dass dieser alle in der URI oder in den Cookies des Benutzers bereitgestellten Informationen entsprechend den Sicherheitsrichtlinien der Anwendung behandelt und verwendet. Bei einem FRAGMENTLINK-Auszeichnungselement überträgt der Entwickler der Anwendung einen Teil der Verantwortung für die ordnungsgemäße Verwendung dieser Informationen an Cachespeicher; ein Cachespeicher, der entsprechend der bevorzugten Ausführungsform der vorliegenden Erfindung ausgeführt ist, sollte die Regel durchsetzen, dass ein FRAGMENTLINK-Auszeichnungselement keine Verknüpfung zu einer anderen Domäne als seiner Elterndomäne herstellen kann.
Eine Seite, die andere Fragmente enthält, wird schließlich zu einer vollständig erweiterten Seite zusammengesetzt, und dies kann überall auf dem Pfad zwischen dem Browser und dem Anwendungs-Server geschehen. Um Sicherheit zu gewährleisten, sollte sich der Entwickler der Anwendung an die folgende Regel halten: ein Fragment erfordert HTTPS, wenn es ein weiteres Fragment enthält, das HTTPS erfordert. Diese Regel sollte rekursiv angewendet werden, so dass sie sich bis hinauf zum Fragment der obersten Ebene durchsetzt. Diese Regel verhindert, dass ein geschütztes Fragment in einem ungeschützten Fragment betrachtet wird.
Bei einer HTTPS-Anforderung sollte der FRAGMENT-Kopfbereich mit einer Anweisung "supports-fragments" nur aufgenommen werden, wenn der Cachespeicher die HTTPS-Sitzung beenden kann. Andernfalls kann er keine FRAGMENTLINKs zu ihrer Verarbeitung erkennen. Ein Cachespeicher, der die HTTPS-Sitzung nicht beendet, kann dennoch Fragmente für HTTP-Anforderungen unterstützen.
Beschreibung einer Cachespeicher-Verwaltungseinheit für einen Cachespeicher, der Fragmente unterstützt
Nun Bezug nehmend auf 6A zeigt ein Blockschaltbild eine Cachespeicher-Verwaltungseinheit für einen Cachespeicher, der Fragmente unterstützt und sich in einer Datenverarbeitungseinheit gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung befindet. Die Datenverarbeitungseinheit 600, die ein Client oder ein Server sein kann oder möglicherweise sowohl über Client- als auch Server-Funktionen verfügen kann, enthält die Cachespeicher-Verwaltungseinheit 602, die Fragmente unterstützt und Funktionen zur Zwischenspeicherung von Objekten für die Datenverarbeitungseinheit 600 enthält. Eine Cachespeicher-Verwaltungseinheit 602 kann beispielsweise als ein dazwischengeschalteter Cachespeicher auf einem Datenpfad zwischen anderen zwischenspeicherungsfähigen Einheiten dienen; in anderen Fällen kann die Cachespeicher-Verwaltungseinheit 602 Objekte in einer Client-Einheit für einen Endbenutzer zwischenspeichern.
Die Cachespeicher-Verwaltungseinheit 602, die Fragmente unterstützt, umfasst die Objektdatenbank 604, um Objekte zu speichern/zwischenzuspeichern, wobei diese Objekte Metadaten einschließen können, welche zu den Objekten und Netzwerk-Kopfbereichen gehören, die zusammen mit den Objekten empfangen wurden. Die Cachespeicher-Verwaltungseinheit 602, die Fragmente unterstützt, umfasst auch Datenbanken zur Speicherung von Informationen in Bezug auf Cachespeicher-Verwaltungsoperationen, die hier erwähnt, aber nachstehend mit Bezug auf die 6B bis 6D ausführlicher erklärt werden.
Die Regellisten-Datenbank 606 speichert URI-Pfade 608 und ihre zugehörigen Regellisten 610. Die Datenbank mit den Cachespeicher-Kennungen 612 speichert Cachespeicher-Kennungen 614 und ihre zugehörigen Cachespeicher-Indizes 616. Die Abhängigkeits-Datenbank 618 speichert die Zuordnung zwischen Abhängigkeits-Kennungen und Cachespeicher-Kennungen. Mehrere Cachespeicher-Kennungen können einer einzigen Abhängigkeit zugeordnet werden, und mehrere Abhängigkeiten können einer einzigen Cachespeicher-Kennung zugeordnet werden.
Beschreibung von einigen der Prozesse in einer Cachespeicher-Verwaltungseinheit für einen Cachespeicher, der Fragmente unterstützt
Nun Bezug nehmend auf 6B zeigt ein Flussdiagramm einen Prozess, der gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, bei der Verarbeitung von Antwortnachrichten, die Fragmente enthalten, verwendet werden kann. Anders ausgedrückt, 6B zeigt einen Prozess, der verwendet werden könnte, um festzustellen, ob und wie ein Objekt in einer Antwortnachricht verarbeitet und/oder in einem Cachespeicher, der Fragmente unterstützt, zwischengespeichert werden sollte.
Der Prozess beginnt, wenn eine Datenverarbeitungseinheit, die eine Cachespeicher-Verwaltungseinheit, welche Fragmente unterstützt, enthält, wie beispielsweise die in 6A gezeigte Datenverarbeitungseinheit, eine Antwortnachricht empfängt (Schritt 6002), zum Beispiel eine HTTP-Antwortnachricht. Anschließend wird festgestellt, ob die Cachespeicher-Verwaltungseinheit den Hauptteil der Nachricht oder den Nutzlastteil in der Antwortnachricht als ein Fragment oder als ein Nicht-Fragment verarbeiten soll (Schritt 6004).
Wenn die Antwortnachricht als eine Antwortnachricht verarbeitet werden soll, die ein Nicht-Fragment enthält, wird festgestellt, ob das Objekt, das kein Fragment ist, unter Anwendung der bestehenden HTTP-1.1-Regeln an dieser Datenverarbeitungseinheit, d. h. von der Cachespeicher-Verwaltungseinheit, zwischengespeichert werden soll und kann (Schritt 6006). Zum Beispiel kann eine Antwortnachricht, die ein Objekt, das kein Fragment ist, enthält, über einen Hinweis verfügen, der besagt, dass sie nicht zwischengespeichert werden soll; in einer HTTP-Antwortnachricht kann ein "Cache-Control"-Kopfbereich eine Anweisung "no-cache" haben. Wenn das Objekt zwischengespeichert werden soll und zwischengespeichert werden kann, wird es von der Cachespeicher-Verwaltungseinheit entsprechend gespeichert (Schritt 6008). Sowohl in dem einen als auch in dem anderen Fall wird die Zwischenspeicherungsoperation für das Objekt durchgeführt, und der Prozess verzweigt, um andere Operationen für die Antwortnachricht durchzuführen.
Wenn die Antwortnachricht als eine Antwortnachricht verarbeitet werden soll, die ein Fragment enthält, wird festgestellt, ob das Fragment zwischengespeichert werden kann (Schritt 6010). Wenn nicht, verzweigt der Prozess, um andere Operationen für die Antwortnachricht durchzuführen. Wenn das Fragment zwischengespeichert werden kann, wird festgestellt, ob dieses bestimmte Fragment im Cachespeicher dieser bestimmten Datenverarbeitungseinheit zwischengespeichert werden soll (Schritt 6012). Wenn nicht, verzweigt der Prozess, um andere Operationen für die Antwortnachricht durchzuführen.
Wenn das Fragment, das gerade verarbeitet wird, in der aktuellen Datenverarbeitungseinheit zwischengespeichert werden soll, wird es von der Cachespeicher-Verwaltungseinheit im Cachespeicher der Datenverarbeitungseinheit gespeichert (Schritt 6014).
Wenn einer der Fälle, in denen das Fragment zwischengespeichert wurde oder in denen festgelegt wurde, dass es nicht in der aktuellen Datenverarbeitungseinheit zwischengespeichert werden soll, oder in denen festgestellt wurde, dass es nicht zwischengespeichert werden kann, eintritt, wird festgestellt, ob eine Seitenzusammensetzung für das Fragment erforderlich ist, bevor die Antwortnachricht weitergeleitet wird (Schritt 6016). Wenn eine Seitenzusammensetzung erforderlich ist, wird sie durchgeführt (Schritt 6018). In jedem Fall wurde das Objekt von der Antwortnachricht, bei dem es sich sowohl um ein Objekt handeln kann, das ein Fragment ist, als auch um ein Objekt, das kein Fragment ist, von der Cachespeicher-Verwaltungseinheit der aktuellen Datenverarbeitungseinheit vollständig verarbeitet, und die Antwortnachricht wird bei Bedarf geändert und an ihr Ziel weitergeleitet (Schritt 6020), womit der Prozess abgeschlossen ist.
Nun Bezug nehmend auf 6C zeigt ein Schritt eines Flussdiagramms ein bevorzugtes Verfahren zur Feststellung, ob ein Nachrichtenhauptteil ein Fragment-Objekt enthält. 6C stellt einen Schritt dar, der den Schritt 6004 in 6B ersetzen kann. In einer bevorzugten Ausführungsform wird festgestellt, ob die empfangene Antwortnachricht einen Nachrichten-/Protokoll-Kopfbereich enthält, der die Nutzlast oder den Nachrichtenhauptteil als Fragment angibt (Schritt 6022). Wie in 4 gezeigt ist, kann insbesondere ein FRAGMENT-Kopfbereich in eine HTTP-Nachricht gestellt werden, um anzugeben, dass die Nutzlast der Nachricht ein Fragment-Objekt enthält.
Nun Bezug nehmend auf 6D zeigt ein Schritt eines Flussdiagramms ein spezielleres Verfahren zur Feststellung, ob ein Fragment-Objekt zwischengespeichert werden kann. 6D stellt einen Schritt dar, der den Schritt 6010 in 6B ersetzen kann. In dieser Ausführungsform wird festgestellt, ob die empfangene Antwortnachricht eine Anweisung für einen Protokoll-Kopfbereich zur Steuerung des Cachespeichers enthält, die das Fragment als ein Fragment ausweist, das zwischengespeichert werden kann (Schritt 6024).
Nun Bezug nehmend auf 6E zeigt ein Schritt eines Flussdiagramms ein bevorzugtes Verfahren zur Feststellung, ob ein Fragment-Objekt zwischengespeichert werden kann. In einer 6D ähnlichen Art und Weise stellt 6E einen Schritt dar, der den Schritt 6010 in 6B ersetzen kann. In einer bevorzugten Ausführungsform wird festgestellt, ob die empfangene Antwortnachricht über eine Anweisung für einen Nachrichten-/Protokoll-Kopfbereich verfügt, der das Fragment gegenüber Cachespeichern, die Fragmente unterstützen, als ein Fragment ausweist, das zwischengespeichert werden kann, und gegenüber Cachespeichern, die keine Fragmente unterstützen, als ein Fragment, das nicht zwischengespeichert werden kann (Schritt 6026). Wie vorstehend erörtert wurde, kann insbesondere ein "Cache-Control"-Kopfbereich in eine HTTP-Nachricht aufgenommen werden, und es ist üblich, eine Anweisung "no-cache" in den "Cache-Control"-Kopfbereich zu stellen, um die Zwischenspeicherung von Objekten zu verhindern; die bevorzugte Ausführungsform der vorliegenden Erfindung behält diese Vorgehensweise bei Cachespeichern, die keine Fragmente unterstützen, bei, während sie die Verwendung des "Cache-Control"-Kopfbereichs dahingehend erweitert, dass eine Anweisung "fragmentrules" aufgenommen wird, um anzugeben, dass das Fragment in einer Nachricht gemäß den Regeln für die Zwischenspeicherung von Fragmenten zwischengespeichert werden kann.
Nun Bezug nehmend auf 6F zeigt ein Flussdiagramm ein Verfahren zur Feststellung, ob ein Fragment-Objekt an einer bestimmten Datenverarbeitungseinheit zwischengespeichert werden soll. 6F zeigt einen Prozess, der die Schritte 6012 und 6014 in 6B ersetzen kann; wenn dieser Prozess aufgerufen wird, wurde bereits festgestellt, dass die Antwortnachricht ein Fragment enthält, das zwischengespeichert werden kann.
Der Prozess beginnt mit der Feststellung, ob eine nachgelagerte Einheit über einen Cachespeicher verfügt, der Fragmente unterstützt (Schritt 6028). Eine nachgelagerte Einheit wäre eine Datenverarbeitungseinheit, an die die aktuelle Datenverarbeitungseinheit die Antwortnachricht weiterleiten würde. Wenn eine nachgelagerte Einheit nicht über einen Cachespeicher verfügt, der Fragmente unterstützt, speichert die Cachespeicher-Verwaltungseinheit der aktuellen Datenverarbeitungseinheit das Fragment-Objekt, das gerade verarbeitet wird (Schritt 6030), und der Prozess ist abgeschlossen.
Wenn eine nachgelagerte Einheit über einen Cachespeicher verfügt, der Fragmente unterstützt, wird festgestellt, ob das Fragment-Objekt, das gerade verarbeitet wird, nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet. Wenn nicht, kann das aktuelle Fragment-Objekt auch an der aktuellen Datenverarbeitungseinheit zwischengespeichert werden, und der Prozess verzweigt zum Schritt 6030, um das Fragment zwischenzuspeichern. Wenn das Fragment jedoch nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet, speichert die aktuelle Datenverarbeitungseinheit das Fragment nicht zwischen, und der Prozess ist abgeschlossen.
Nun Bezug nehmend auf 6G zeigt ein Schritt eines Flussdiagramms ein bevorzugtes Verfahren zur Feststellung, ob eine nachgelagerte Einheit über einen Cachespeicher verfügt, der Fragmente unterstützt. 6G stellt einen Schritt dar, der den Schritt 6028 in 6F ersetzen kann. 6F und 6G zeigen Prozesse, die nach dem Empfang einer Antwortnachricht eingeleitet werden; die Antwortnachricht würde empfangen werden, weil die aktuelle Datenverarbeitungseinheit zuvor eine Anforderungsnachricht empfangen und weitergeleitet hat. Daher hat die Cachespeicher-Verwaltungseinheit zu dem Zeitpunkt, zu dem die Antwortnachricht empfangen wird, eine bestimmte Art von Zustandsinformationen für die zuvor empfangene Anforderungsnachricht verwaltet.
In Bezug auf die Feststellung, ob eine nachgelagerte Einheit über einen Cachespeicher verfügt, der Fragmente unterstützt, wird in einer bevorzugten Ausführungsform festgestellt, ob die zuvor empfangene Anforderungsnachricht einen Nachrichten- /Protokoll-Kopfbereich mit einer Anweisung enthalten hat, die angibt, dass Fragmente unterstützt werden (Schritt 6034). Wie in 4 gezeigt ist, kann insbesondere ein FRAGMENT-Kopfbereich in eine HTTP-Nachricht gestellt werden, und der FRAGMENT-Kopfbereich kann eine Anweisung "supports-fragments" enthalten.
Nun Bezug nehmend auf 6H zeigt ein Schritt eines Flussdiagramms ein spezielleres Verfahren zur Feststellung, ob das Fragment-Objekt, das gerade verarbeitet wird, nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet. 6H stellt einen Schritt dar, der den Schritt 6032 in 6F ersetzen kann. In dieser Ausführungsform hat die Antwortnachricht, die von der aktuellen Datenverarbeitungseinheit gerade verarbeitet wird, einen Nachrichten-/Protokoll-Kopfbereich, der eine Anweisung vom Ursprungsserver enthält, die angibt, dass das Fragment in der Antwortnachricht nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet (Schritt 6036).
Nun Bezug nehmend auf 6I zeigt ein Schritt eines Flussdiagramms ein bevorzugtes Verfahren zur Feststellung, ob das Fragment-Objekt, das gerade verarbeitet wird, nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet. In einer 6H ähnlichen Art und Weise stellt 6I einen Schritt dar, der den Schritt 6032 in 6F ersetzen kann. In einer bevorzugten Ausführungsform hat die Antwortnachricht, die von der aktuellen Datenverarbeitungseinheit gerade verarbeitet wird, einen HTTP-Nachrichten-/Protokoll-Kopfbereich "Cache-Control", der eine Anweisung "private" vom Ursprungsserver enthält, die Cachespeichern, die Fragmente unterstützen, gegenüber angibt, dass das Fragment in der Antwortnachricht nur in dem Cachespeicher zwischengespeichert werden soll, der Fragmente unterstützt und sich in nächster Nähe der Benutzer-/Client-Zieleinheit befindet (Schritt 6038).
Nun Bezug nehmend auf 6J zeigt ein Flussdiagramm ein Verfahren zur Feststellung, ob eine Seitenzusammensetzung erforderlich ist, bevor eine Antwortnachricht von der aktuellen Datenverarbeitungseinheit zurückgeschickt wird. 6J zeigt einen Prozess, der die Schritte 6016 und 6018 in 6B ersetzen kann; wenn dieser Prozess aufgerufen wird, wurde das Fragment von der Antwortnachricht bei Bedarf bereits zwischengespeichert.
Der Prozess beginnt mit der Feststellung, ob eine nachgelagerte Einheit über einen Cachespeicher verfügt, der Fragmente unterstützt (Schritt 6040), beispielsweise in einer dem Schritt 6028 in 6F ähnlichen Weise. Wenn eine nachgelagerte Einheit über einen Cachespeicher verfügt, der Fragmente unterstützt, ist keine Seitenzusammensetzung erforderlich, und der Prozess ist abgeschlossen. Wenn eine nachgelagerte Einheit nicht über einen Cachespeicher verfügt, der Fragmente unterstützt, wird festgestellt, ob das Fragment, das gerade verarbeitet wird, eine Verknüpfung zu einem anderen Fragment hat (Schritt 6042). Wenn nicht, ist keine Seitenzusammensetzung erforderlich, und der Prozess ist abgeschlossen. Wenn in dem aktuellen Fragment eine Verknüpfung zu einem anderen Fragment vorhanden ist, wird eine Seitenzusammensetzung durchgeführt (Schritt 6044), und der Prozess ist abgeschlossen.
Nun Bezug nehmend auf 6K zeigt ein Schritt eines Flussdiagramms ein spezielleres Verfahren zur Feststellung, ob das Fragment-Objekt, das gerade verarbeitet wird, eine Verknüpfung zu einem anderen Fragment hat. 6K stellt einen Schritt dar, der den Schritt 6042 in 6J ersetzen kann. In dieser Ausführungsform wird festgestellt, ob das aktuelle Fragment ein Element einer Auszeichnungssprache hat, das ein mit einer semantischen Auszeichnung versehenes Element enthält, welches eine Quellenkennung oder einen Ursprungsort eines aufzunehmenden Fragments angibt (Schritt 6046). Wie in 3 gezeigt ist, kann insbesondere ein FRAGMENTLINK-Element in den Hauptteil eines HTML-Objekts gestellt werden, um eine Verknüpfung zu einem anderen Fragment anzugeben. In der HTTP-Spezifikation wird eine Quellenkennung als "Request-URI" ("Anforderungs-URI") bezeichnet, d. h. als eine Kennung, die die Ressource ausweist, auf die die Anforderung angewendet werden soll.
Nun Bezug nehmend auf 6L zeigt ein Schritt eines Flussdiagramms ein alternatives Verfahren zur Feststellung, ob das Fragment-Objekt, das gerade verarbeitet wird, eine Verknüpfung zu einem anderen Fragment hat. In einer 6K ähnlichen Art und Weise stellt 6L einen Schritt dar, der den Schritt 6042 in 6J ersetzen kann. In dieser alternativen Ausführungsform wird festgestellt, ob die Antwortnachricht, die gerade verarbeitet wird, einen Nachrichten-/Protokoll-Kopfbereich mit einer Anweisung enthält, die angibt, dass das Fragment im Nachrichtenhauptteil der Antwortnachricht, d. h. das Fragment, das gerade verarbeitet wird, eine Verknüpfung zu einem anderen Fragment hat (Schritt 6048). Dies könnte festgestellt werden, indem das Fragment nach einem FRAGMENTLINK abgefragt wird. Es ist jedoch wesentlich sinnvoller, dies mit einem Antwort-Kopfbereich anzugeben, so dass unnötige Abfragen vermieden werden. Wie in 4 gezeigt ist, kann insbesondere ein FRAGMENT-Kopfbereich in eine HTTP-Nachricht gestellt werden, und der FRAGMENT-Kopfbereich kann eine Anweisung "contains-fragments" enthalten. Diese Anweisung ermöglicht der Cachespeicher-Verwaltungseinheit der aktuellen Datenverarbeitungseinheit, bei der Suche nach einem FRAGMENTLINK-Element auf eine Abfrage des aktuellen Fragments zu verzichten.
Nun Bezug nehmend auf 6M zeigt ein Flussdiagramm einen Prozess zur Durchführung einer Seitenzusammensetzung. 6M stellt einen Schritt dar, der den Schritt 6018 in 6B oder den Schritt 6044 in 6J ersetzen kann. Der Prozess beginnt mit der Anforderung der Quellenkennung, z. B. der URI, des verknüpften Fragments, die in dem aktuellen Fragment von der Antwortnachricht enthalten ist (Schritt 6050). Das verknüpfte Fragment wird dann mit Hilfe der Quellenkennung abgerufen (Schritt 6052). Das abgerufene Fragment und das aktuelle Fragment von der Antwortnachricht werden dann zusammengefasst, um eine zusammengesetzte Seite zu bilden (Schritt 6054), d. h., ein neues Fragment zu bilden, und der Prozess ist abgeschlossen.
Das Zusammenfassen des Inhalts von Fragmenten ist von den Codierregeln für den Inhaltstyp der Fragmente abhängig. Jedes Element in einer Auszeichnungssprache kann zum Beispiel als ein Fragment betrachtet werden, und ein Kindelement kann in ein Elternelement eingebettet werden, indem das mit einer semantischen Auszeichnung versehene Element in die Begrenzungsmarkierungen des Elternelements eingefügt wird. Das Zusammenfassen von Fragmenten macht es jedoch erforderlich, dass die Art und Weise berücksichtigt wird, in der die Kopfbereiche und die Merkmalswerte der Fragmente kombiniert werden, wie nachstehend ausführlicher erörtert wird.
Nun Bezug nehmend auf 6N zeigt ein Flussdiagramm einen Prozess, um eine Fragmentverknüpfung optional auf mehrere Fragmentverknüpfungen zu erweitern. Nochmals Bezug nehmend auf 6M könnten die Schritte 6050 und 6052 in dem Fall, in dem das aktuelle Fragment mehrere Fragmentverknüpfungen enthält, so oft wie nötig wiederholt werden, um die diversen verknüpften Fragmente abzurufen, die dann alle zusammengefasst werden könnten, um eine einzelne zusammengesetzte Seite zu bilden. Im Gegensatz dazu zeigt 6N einen Prozess, mittels dessen eine einzelne Fragmentverknüpfung kompakt so bezeichnet werden kann, dass sie Verweise auf mehrere Fragmente enthält, die zusammengefasst werden, um eine zusammengesetzte Seite zu bilden.
Der Prozess beginnt mit der Feststellung, ob die Fragmentverknüpfung in dem aktuellen Fragment von der Antwortnachricht angibt, dass sie auf mehrere Fragmentverknüpfungen erweitert werden soll (Schritt 6062). Wenn nicht, ist der Prozess beendet; wenn ja, wird die Fragmentverknüpfung auf eine aus mehreren Fragmentverknüpfungen bestehende Gruppe erweitert, wobei Informationen verwendet werden, die zu der Fragmentverknüpfung gehören (Schritt 6064).
Die diversen Fragmentverknüpfungen werden dann in einer Schleife verarbeitet. Die nächste Fragmentverknüpfung in der aus mehreren Fragmentverknüpfungen bestehenden Gruppe wird abgerufen (Schritt 6066), und die Quellenkennung für die Fragmentverknüpfung wird ebenfalls abgerufen (Schritt 6068). Das gekennzeichnete Fragment wird dann mit Hilfe der Quellenkennung abgerufen (Schritt 6070). Es wird festgestellt, ob noch eine weitere Fragmentverknüpfung in der aus mehreren Fragmentverknüpfungen bestehenden Gruppe vorhanden ist (Schritt 6072), und wenn ja, verzweigt der Prozess zum Schritt 6066 zurück, um eine weitere Fragmentverknüpfung zu verarbeiten. Wenn es keine weiteren Fragmentverknüpfungen mehr gibt, was bedeutet, dass alle Fragmente abgerufen worden sind, werden alle abgerufenen Fragmente und das Fragment von der ursprünglichen Antwortnachricht zusammengefasst (Schritt 6074), und der Prozess ist abgeschlossen.
Nun Bezug nehmend auf 6O zeigt ein Schritt eines Flussdiagramms ein bevorzugtes Verfahren zur Feststellung, ob die Fragmentverknüpfung in dem aktuellen Fragment von der Antwortnachricht angibt, dass sie auf mehrere Fragmentverknüpfungen erweitert werden soll. 6O stellt einen Schritt dar, der den Schritt 6062 in 6N ersetzen kann. In einer bevorzugten Ausführungsform wird festgestellt, ob ein mit einer semantischen Auszeichnung einer Auszeichnungssprache versehenes Element für die Fragmentverknüpfung in dem Fragment von der Antwortnachricht ein Attribut enthält, das angibt, dass die Fragmentverknüpfung erweitert werden soll (Schritt 6076). Wie in 3 gezeigt ist, kann insbesondere ein FRAGMENTLINK-Element ein Attribut FOREACH haben.
Nun Bezug nehmend auf 6P zeigt ein Flussdiagramm einen Prozess, um eine Fragmentverknüpfung gemäß Informationen, die zu der Fragmentverknüpfung gehören, auf mehrere Fragmentverknüpfungen zu erweitern. 6P stellt eine Reihe von Schritten dar, die den Schritt 6064 in 6N ersetzen können.
Der Prozess beginnt mit der Anforderung eines Cookie-Namens von dem aufgenommenen, mit einer semantischen Auszeichnung einer Auszeichnungssprache versehenen Elements für die Fragmentverknüpfung (Schritt 6078). Wie in 3 gezeigt ist, kann ein Attribut FOREACH eine Zeichenkette bereitstellen, die als der Name eines Cookie ausgewertet wird. Der Wert des Cookie wird abgerufen (Schritt 6080); der Wert des Cookie ist eine Zeichenkette, die eine Liste von Namen-Wert-Paaren darstellt, wie dann in einer Schleife verarbeitet werden. Das nächste Namen-Wert-Paar wird aus dem Wert des Cookie abgerufen (Schritt 6082), und eine Fragmentverknüpfung wird unter Verwendung des Namen-Wert-Paares erzeugt, z. B. indem der Namen-Wert-Paar als Abfrageparameter verwendet wird (Schritt 6084). Anschließend wird festgestellt, ob noch ein weiteres Namen-Wert-Paar in dem Wert des Cookie vorhanden ist (Schritt 6086), und wenn ja, verzweigt der Prozess zum Schritt 6082 zurück, um ein weiteres Namen-Wert-Paar zu verarbeiten. Zum Beispiel könnte für jedes Namen-Wert-Paar ein FRAGMENTLINK-Element erzeugt werden und dadurch das ursprüngliche FRAGMENTLINK-Element auf eine aus mehreren FRAGMENTLINK-Elementen bestehende Gruppe erweitert werden, die das ursprüngliche FRAGMENTLINK-Element ersetzen. Wenn es keine weiteren Namen-Wert-Paare mehr gibt, ist der Prozess beendet.
Nun Bezug nehmend auf 6Q zeigt ein Flussdiagramm einen Prozess, um ein Fragment unter Verwendung einer Quellenkennung für das Fragment abzurufen. 6Q stellt einen Prozess dar, der den Schritt 6052 in 6M oder den Schritt 6070 in 6N ersetzen kann; der Prozess in 6Q beginnt, nachdem bereits eine Quellenkennung für ein Fragment ermittelt worden ist.
Der Prozess beginnt mit der Feststellung, ob es bei der Quellenkennung in dem lokalen Cachespeicher an der aktuellen Datenverarbeitungseinheit einen Cache-Treffer gibt (Schritt 6092). Wenn ja, kann das Fragment aus dem Cachespeicher abgerufen werden (Schritt 6094), und das abgerufene Fragment wird an die aufrufende Routine zurückgeschickt (Schritt 6096). Wenn das abgerufene Fragment eine Fragmentverknüpfung enthält, kehrt der Prozess in einer Schleife zum Schritt 6092 zurück, um das von der Fragmentverknüpfung angegebene Fragment abzurufen (Schritt 6098), wodurch der Prozess fortgesetzt wird, um alle Kindfragmente abzurufen.
Wenn es bei der Quellenkennung in dem lokalen Cachespeicher im Schritt 6092 einen missglückten Cachespeicher-Zugriff gab, wird eine Anforderungsnachricht erzeugt (Schritt 6100) und unter Verwendung der Quellenkennung als Zielkennung gesendet (Schritt 6102). Wie mit Bezug auf 4 erklärt wurde, würde die Anforderungsnachricht eine Anweisung "supports-fragments" enthalten, da die aktuelle Datenverarbeitungseinheit eine Cachespeicher-Verwaltungseinheit enthält, die Fragmente unterstützt. Die Cachespeicher-Verwaltungseinheit erwartet dann eine Antwort auf die Anforderungsnachricht (Schritt 6104). Vorzugsweise wird für die Anforderung ein ausführbares Programmsegment (thread) erzeugt, und das Programmsegment befindet sich im Ruhemodus, während er auf eine Antwort wartet und während die Datenverarbeitungseinheit andere Operationen durchführt.
Nachdem eine Antwortnachricht empfangen wurde, wird das Fragment im Nachrichtenhauptteil der Antwortnachricht abgerufen (Schritt 6106) und zwischengespeichert (Schritt 6108). Wie zuvor erwähnt wurde, wird das abgerufene Fragment an die aufrufende Routine zurückgeschickt, und wenn das abgerufene Fragment eine Fragmentverknüpfung enthält, kehrt der Prozess in einer Schleife zum Schritt 6092 zurück, um das von der Fragmentverknüpfung angegebene Fragment abzurufen, wodurch der Prozess fortgesetzt wird, um alle Kindfragmente abzurufen. Andernfalls ist der Prozess des Abrufens eines Fragments abgeschlossen.
Nun Bezug nehmend auf 6R zeigt ein Flussdiagramm einen Teil der Verarbeitung, die durchgeführt wird, wenn ein Fragment in der Cachespeicher-Verwaltungseinheit zwischengespeichert wird, die Fragmente unterstützt. 6R stellt einen Prozess dar, der den Schritt 6014 in 6B oder den Schritt 6030 in 6F ersetzen kann; der Prozess in 6R beginnt, nachdem bereits ein Fragment in einer Antwortnachricht an der aktuellen Datenverarbeitungseinheit empfangen worden ist.
Der Prozess beginnt damit, dass die Quellenkennung, die zu dem Fragment gehört, z. B. die URI in der Antwortnachricht (Schritt 6112), zusammen mit der Regelliste, die zu dem Fragment gehört, abgerufen wird (Schritt 6114), sofern eine Regelliste in der Antwortnachricht vorhanden ist. Die Regelliste wird in der Regellisten-Datenbank in Verbindung mit dem URI-Pfad zur späteren Verwendung gespeichert (Schritt 6116), wenn versucht wird, einen Cache-Treffer für eine Anforderung zu erzielen, die gerade verarbeitet wird. Die Regelliste wird verwendet, um die Erzeugung einer Cachespeicher-Kennung zur Zwischenspeicherung des Fragments in der Antwortnachricht zu steuern (Schritt 6118).
Die Cachespeicher-Kennung wird dann zur Erzeugung eines Cachespeicher-Index verwendet (Schritt 6120); der Cachespeicher-Index dient zur Bestimmung des Speicherorts in dem Fragmentspeicher, d. h. in dem Cachespeicher, an dem das Fragment von der Antwortnachricht gespeichert werden soll. Der Cachespeicher-Index kann erzeugt werden, indem man die Cachespeicher-Kennung einen Hashing-Algorithmus durchlaufen lässt. Das Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung ist flexibel, da die jeweils gegebene Art der Ausführung einer Cachespeicher-Verwaltungseinheit ihren eigenen Algorithmus zur Berechnung eines Cachespeicher-Index verwenden kann, nachdem die Cachespeicher-Kennung in einer Weise erzeugt worden ist, die das Verfahren zur Anwendung von Regeln für Cachespeicher-Kennungen befolgt, die ein Fragment begleiten.
Das Fragment wird dann im Cachespeicher zusammen mit anderen notwendigen Informationen oder Metadaten einschließlich der Kopfbereiche in der HTTP-Antwortnachricht, die dem Fragment beigefügt war, oder gleichwertiger Informationen gespeichert (Schritt 6122), und die neu erzeugte Cachespeicher-Kennung wird dann in Verbindung mit dem Cachespeicher-Index gespeichert (Schritt 6124). Alternativ dazu könnte der Cachespeicher-Index wann immer nötig berechnet werden, so dass gegebenenfalls keine Notwendigkeit besteht, den Cachespeicher-Index zu speichern. Als eine weitere Alternative könnte die Cachespeicher-Kennung direkt als eine Art von Speicherindex oder Datenbank-Kennung verwendet werden, so dass nicht unbedingt ein gesonderter Cachespeicher-Index berechnet werden muss.
Wenn es in der Antwortnachricht Abhängigkeiten gibt, die zu dem Fragment gehören, werden die Abhängigkeiten abgerufen (Schritt 6126) und in Verbindung mit der Cachespeicher-Kennung des Fragments gespeichert (Schritt 6128).
Nun Bezug nehmend auf 6S zeigt ein Flussdiagramm einen Prozess, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, verwendet werden kann, um ein Fragment abzurufen, wenn es an einer Datenverarbeitungseinheit zwischengespeichert ist, die die Cachespeicher-Verwaltungseinheit enthält. Anders ausgedrückt, 6S zeigt einen Prozess, der verwendet werden könnte, um festzustellen, ob in einem Cachespeicher, der Fragmente unterstützt, ein Cache-Treffer beispielsweise als Reaktion auf das Prüfen einer Anforderungsnachricht erzeugt werden kann.
Der Prozess beginnt mit dem Abrufen der Quellenkennung, z. B. einem URI-Pfad, die zu einer Anforderung gehört (Schritt 6132). Daraufhin wird die Regellisten-Datenbank durchsucht, um festzustellen, ob in der Regellisten-Datenbank für den URI-Pfad eine Regelliste mit Cachespeicher-Kennungen vorhanden ist (Schritt 6134). Wenn es keine dem URI-Pfad zugeordnete Regelliste gibt, wird eine Meldung über einen missglückten Cachespeicher-Zugriff zurückgeschickt (Schritt 6136), und der Prozess ist abgeschlossen.
Wenn es eine dem URI-Pfad zugeordnete Regelliste gibt, werden die Regeln in der Regelliste zur Erzeugung einer Cachespeicher-Kennung angewendet (Schritt 6138), wobei davon ausgegangen wird, dass eine Cachespeicher-Kennung erzeugt werden kann, d. h., dass alle erforderlichen Informationen vorhanden sind, damit wenigstens eine Regel erfolgreich ausgewertet werden kann. Anschließend wird festgestellt, ob die Cachespeicher-Kennung zuvor schon zur Speicherung eines Fragments verwendet worden ist (Schritt 6140), d. h., ob es einen Cache-Treffer gibt. Wenn nicht, wird eine Meldung über einen missglückten Cachespeicher-Zugriff zurückgeschickt, und der Prozess ist beendet.
Wenn es einen Cache-Treffer gibt, wird der Cachespeicher-Index, der zu der Cachespeicher-Kennung gehört, abgerufen (Schritt 6142), was den anschließenden Abruf des entsprechenden Fragments mittels des Cachespeicher-Index ermöglicht (Schritt 6144). Das Fragment wird dann an den Anforderer zurückgeschickt (Schritt 6146), wodurch der Prozess abgeschlossen wird.
Nun Bezug nehmend auf 6T zeigt ein Flussdiagramm einen Prozess zum Zusammenfassen von Kopfbereich-Werten und Merkmalswerten, die zu einer Vielzahl von Fragmenten gehören. 6T stellt einen Prozess dar, der den Schritt 6054 in 6M oder den Schritt 6074 in 6N ersetzen kann. Jedes Fragment, das für eine Zusammenfassung vorgesehen ist, ungeachtet dessen, ob es in einer Antwortnachricht empfangen oder aus dem Cachespeicher der Datenverarbeitungseinheit abgerufen worden ist, verfügt über einen zugeordneten Satz von Protokoll-Kopfbereichen, die mit jedem Fragment in einer Antwortnachricht empfangen wurden. Die Werte der Kopfbereiche und der Merkmale werden zu einer einzigen Anweisung beziehungsweise zu einem einzigen Wert für jeden Kopfbereich oder für jedes Merkmal zusammengefasst.
Der Prozess beginnt mit dem Abrufen der Kopfbereich-Werte für einen nächsten Kopfbereich-Typ von allen Fragmenten, die zusammengefasst werden sollen (Schritt 6152). Eine geeignete Zusammenfassungsfunktion wird dann auf all diese Kopfbereich-Werte angewendet (Schritt 6154), und der zusammengefasste Kopfbereich-Wert wird daraufhin gesetzt beziehungsweise der zusammengesetzten Seite oder dem zusammengesetzten Fragment zugeordnet (Schritt 6156). Anschließend wird festgestellt, ob es noch einen weiteren Kopfbereich-Typ gibt, der verarbeitet werden muss (Schritt 6158), und wenn ja, verzweigt der Prozess zum Schritt 6152 zurück, um einen weiteren Kopfbereich-Typ zu verarbeiten.
Nachdem alle Kopfbereiche verarbeitet worden sind, ruft der Prozess die Merkmalswerte für einen nächsten Merkmalstyp von allen Fragmenten ab, die zusammengefasst werden sollen (Schritt 6160). Eine geeignete Zusammenfassungsfunktion wird dann auf all diese Merkmalswerte angewendet (Schritt 6162), und der zusammengefasste Merkmalswert wird daraufhin gesetzt beziehungsweise der zusammengesetzten Seite oder dem zusammengesetzten Fragment zugeordnet (Schritt 6164). Anschließend wird festgestellt, ob es noch einen weiteren Merkmalstyp gibt, der verarbeitet werden muss (Schritt 6166), und wenn ja, verzweigt der Prozess zum Schritt 6160 zurück, um einen weiteren Merkmalstyp zu verarbeiten; andernfalls ist der Prozess abgeschlossen.
Nun Bezug nehmend auf 6U zeigt ein Flussdiagramm mehrere Schritte, die eine Reihe von Funktionen zum Zusammenfassen von Kopfbereich-Typen und Merkmalswerten darstellen. 6U stellt einige Zusammenfassungsfunktionen dar, die in den Schritten 6154 oder 6162 in 6T verwendet werden könnten; die Zusammenfassungsfunktionen, die gezeigt sind, sind nicht als eine vollständige Liste von Zusammenfassungsfunktionen zu verstehen, die in einer Cachespeicher-Verwaltungseinheit vorhanden sein könnten.
Der Prozess beginnt mit der Feststellung, ob gerade ein HTTP-Feld "Content-Length" zusammengefasst wird (Schritt 6168). Wenn nicht, wird der nächste Schritt übersprungen; andernfalls ist der Wert des zusammengefassten "Content-Length"-Feldes die Summe aller "Content-Length"-Felder (Schritt 6170).
Der Prozess wird mit der Feststellung fortgesetzt, ob gerade ein HTTP-Feld "Last-Modified" zusammengefasst wird (Schritt 6172). Wenn nicht, wird der nächste Schritt übersprungen; andernfalls ist der Wert des zusammengefassten "Last-Modified"-Feldes der neueste Wert von allen "Last-Modified"-Feldern (Schritt 6174).
Der Prozess wird mit der Feststellung fortgesetzt, ob gerade Verfallszeitwerte zusammengefasst werden (Schritt 6176). Wenn nicht, wird der nächste Schritt übersprungen; andernfalls wird der Wert der zusammengefassten Verfallszeitwerte gemäß den folgenden Überlegungen gesetzt (Schritt 6178). Die Beziehung zwischen den Antwort-Kopfbereichen, die auf der Grundlage der Uhrzeit ungültig gemacht werden und sich in den Fragmenten befinden, und denjenigen in der zusammengesetzten Seite sollten von einem Cachespeicher, der Fragmente unterstützt, beachtet werden. Der Zusammensetzungsprozess sollte die Zeitpunkte zum Ungültigmachen für die zusammengesetzte Seite wie folgt ermitteln. Zunächst wird aus dem Kopfbereich "Expires", bei dem es sich um einen absoluten Zeitpunkt handelt, dem Kopfbereich "Cache-Control" mit einer Anweisung "max-age", bei dem es sich um einen relativen Zeitpunkt handelt, und dem Kopfbereich "Date" eines jeden Fragments das kürzeste gleiche Zeitintervall aller Fragmente, einschließlich des Fragments der obersten Ebene und aller rekursiv enthaltenen Fragmente, berechnet. Dies geschieht, indem absolute Zeitpunkt in Delta-Zeitpunkte umgewandelt werden, wobei der Wert des Kopfbereichs "Date" verwendet wird. Dieser Wert kann als "minimumRelativeTime" bezeichnet werden. Als Zweites wird der Wert im Kopfbereich "Expires" der zusammengesetzten Seite auf den Wert im Kopfbereich "Date" zuzüglich des berechneten Werts minimumRelativeTime gesetzt. Dies ist bei Cachespeichern erforderlich, die den HTTP/1.1-Kopfbereich "Cache-Control" nicht unterstützen. Als Drittes wird die Anweisung "max-age" der zusammengesetzten Seite auf den berechneten Wert minimumRelativeTime gesetzt, da die HTTP/1.1-Spezifikation vorschreibt, dass die Anweisung "max-age" den Kopfbereich "Expires" selbst dann außer Kraft setzt, wenn der Kopfbereich "Expires" mit mehr Einschränkungen verbunden ist. Dies ist bei Cachespeichern erforderlich, die den HTTP/1.1-Kopfbereich "Cache-Control" unterstützen.
Der letzte Schritt in dem Prozess setzt den Typ, der Inhalte codiert, auf einen geeigneten Wert (Schritt 6180). Bei einer ersten Alternative nach der HTTP/1.1-Spezifikation kann der Cachespeicher die Codierung des Inhalts ändern, wenn die neue Codierung als eine für den Client annehmbare Codierung bekannt ist, vorausgesetzt, dass es in keinem der Kopfbereiche, die gerade zusammengefasst werden, keine Cachespeicher-Steuerungsanweisung "no-transform" gibt. Bei einer zweiten Alternative werden die Codierungen des Inhalts der enthaltenen Fragmente so geändert, dass sie gleich dem Fragment der obersten Ebene sind.
Nun Bezug nehmend auf 6V zeigt ein Flussdiagramm einen Prozess, der von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, bei der Verarbeitung von Anforderungsnachrichten verwendet werden kann. Im Gegensatz zu 6B, die die Verarbeitung einer Antwortnachricht zeigt, zeigt 6V ein paar der Schritte in Verbindung mit der Verarbeitung einer Anforderungsnachricht.
Der Prozess beginnt mit dem Empfang einer Anforderungsnachricht (Schritt 6192), woraufhin die Quellenkennung von der Anforderungsnachricht abgerufen wird (Schritt 6194). Die Quellenkennung wird verwendet, um entweder das gekennzeichnete Objekt oder das gekennzeichnete Fragment aus dem lokalen Cachespeicher abzurufen, d. h., ein Cache-Treffer findet statt, oder um das Objekt oder Fragment mittels einer Anforderung abzurufen, d. h., ein missglückter Cachespeicher-Zugriff findet statt (Schritt 6196). Der mit einem Cache-Treffer oder einem missglückten Cachespeicher-Zugriff verbundene Prozess wurde vorstehend mit Bezug auf 6Q beschrieben. In beiden Fällen wird eine Seitenzusammensetzung durchgeführt (Schritt 6198), wenn sie erforderlich ist; der mit der Seitenzusammensetzung verbundene Prozess wurde vorstehend mit Bezug auf 6T beschrieben. Anschließend wird eine Antwortnachricht auf die empfangene Anforderungsnachricht zurückgeschickt (Schritt 6200), wodurch der Prozess abgeschlossen wird.
Nun Bezug nehmend auf 6W zeigt ein Flussdiagramm einen Prozess, der gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung von einer Cachespeicher-Verwaltungseinheit, die Fragmente unterstützt, bei der Verarbeitung von Nachrichten über Ungültigmachungen verwendet werden kann. Wie vorstehend erwähnt wurde, schreibt das Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung keinen bestimmten Algorithmus zum Ungültigmachen vor, und der in 6W dargestellte Prozess dient lediglich als Beispiel für die Verwendung der Abhängigkeitskennungen.
Der Prozess beginnt mit dem Empfang einer Anforderungsnachricht für eine Ungültigmachung an einer Datenverarbeitungseinheit von einem Ursprungsserver, der Fragmente veröffentlicht oder bereitgestellt hat, die in der Datenverarbeitungseinheit zwischengespeichert werden können (Schritt 6202). Diese Anforderung enthält eine Liste mit Abhängigkeitskennungen. Es wird davon ausgegangen, dass ein Ursprungsserver keine Abhängigkeiten erzeugt, die einen Konflikt auslösen; indem die Abhängigkeiten mit einer Anwendungskennung klassifiziert werden, welche zumindest ihren Domänennamen enthält, wird davon ausgegangen, dass global eindeutige Abhängigkeiten beibehalten werden können. Normalerweise ist eine Identitätsprüfung erforderlich, um die Anwendungskennung dem Programm zum Ungültigmachen zuzuordnen, so dass ein Programm zum Ungültigmachen nur seinen eigenen Inhalt ungültig machen kann.
Anschließend wird festgestellt, ob eine der Abhängigkeiten in der Abhängigkeits-Datenbank mit der einen oder den mehreren Abhängigkeiten in der empfangenen Nachricht übereinstimmt (Schritt 6210), und wenn ja, wird die Liste der Cachespeicher-Kennungen, die zu der übereinstimmenden Abhängigkeit (oder den übereinstimmenden Abhängigkeiten) gehören, abgerufen (Schritt 6212). Mit den Cachespeicher-Kennungen werden dann zugehörige Fragmente aus dem Cachespeicher gelöscht (Schritt 6214). Wenn es notwendig oder angemessen erscheint, können auch zugehörige Regellisten und Abhängigkeiten gelöscht werden.
Eine optionale Antwort kann an den Ersteller der Anforderungsnachricht für die Ungültigmachung zurückgeschickt werden (Schritt 6216). Wenn es keine übereinstimmenden Abhängigkeiten gab, verzweigt der Prozess zum Schritt 6216. In jedem Fall ist der Prozess abgeschlossen.
Beispiele für einen Teil der Koordination zwischen Cachespeicher-Verwaltungseinheiten für Cachespeicher, die Fragmente unterstützen
Nun Bezug nehmend auf 7A zeigt ein Blockschaltbild einen Teil des Datenflusses zwischen einem Web-Anwendungs-Server und einem Client, um zu veranschaulichen, wann manche Cachespeicher eine Zusammensetzung von Fragmenten durchführen. Die Client-Einheit 700 umfasst eine Cachespeicher-Verwaltungseinheit 702, die keine Fragmente unterstützt und die eine Anforderung für eine Seite erzeugt und die Anforderung an den dazwischengeschalteten Server 704 sendet. Ohne dass dies der Client-Einheit bekannt ist, umfasst die angeforderte Seite tatsächlich ein Elternfragment und eine Verknüpfung zu einem Kindfragment. Der dazwischengeschaltete Server 704 empfangt die Anforderung, aber die Cachespeicher-Verwaltungseinheit 706 unterstützt weder Fragmente noch verfügt sie über eine zwischengespeicherte Version der angeforderten Seite.
Die Anforderung wird dann an den dazwischengeschalteten Server 708 weitergeleitet, der eine Cachespeicher-Verwaltungseinheit 710, die Fragmente unterstützt, umfasst. Der dazwischengeschaltete Server 708 verfügt nicht über eine zwischengespeicherte Version der angeforderten Seite; der dazwischengeschaltete Server 708 fügt einen Kopfbereich "Fragment: supports-fragments" zu der Anforderungsnachricht hinzu, bevor er die Anforderungsnachricht an den dazwischengeschalteten Server 712 sendet, der eine Cachespeicher-Verwaltungseinheit 714, die keine Fragmente unterstützt, umfasst. Der dazwischengeschaltete Server 712 verfügt nicht über eine zwischengespeicherte Version der angeforderten Seite und sendet beziehungsweise leitet die Anforderungsnachricht an den Web-Anwendungs-Server 716 weiter, der eine Cachespeicher-Verwaltungseinheit 718, die Fragmente unterstützt, umfasst.
Anhand der eingehenden Anforderungsnachricht, die den Kopfbereich "Fragment: supports-fragments" enthält, kann der Web-Anwendungs-Server 716 feststellen, ob eine nachgelagerte Datenverarbeitungseinheit über eine Cachespeicher-Verwaltungseinheit verfügt, die Fragmente unterstützt und die Funktion einer Seitenzusammensetzungseinheit übernehmen kann. Statt die ganze zusammengesetzte Seite in der Antwort zurückzusenden, schickt der Web-Anwendungs-Server 716 eine Antwort mit einem Elternfragment zurück, das ein FRAGMENTLINK-Kindfragment enthält. Der dazwischengeschaltete Server 712 unterstützt keine Fragmente, so dass er die Antwort lediglich weiterleitet.
Die Cachespeicher-Verwaltungseinheit 710, die Fragmente unterstützt, erkennt, dass sie derjenige Fragmente unterstützende Cachespeicher ist, der sich in nächster Nähe des Endbenutzers oder des Clients befindet; die ursprüngliche Anforderung enthielt keinen Kopfbereich "Fragment: supports-fragments", so dass die Cachespeicher-Verwaltungseinheit 710, die Fragmente unterstützt, feststellt, dass sie eine Seitenzusammensetzung durchführen sollte, bevor sie die Antwort zurückschickt. Während des Prozesses der Seitenzusammensetzung fordert die Cachespeicher-Verwaltungseinheit 710 das Kindfragment an, das mit dem Elternfragment verknüpft ist, und empfängt es; das Kindfragment und das Elternfragment werden zu einer einzigen zusammengesetzten Seite zusammengefasst, und die zusammengesetzte Seite wird an die Client-Einheit zurückgeschickt. Der dazwischengeschaltete Server 704 leitet die Antwort an die Client-Einheit 700, die die zusammengesetzte Seite dann dem Endbenutzer übergibt. Weder der dazwischengeschaltete Server 704 noch die Client-Einheit 700 würde die zusammengesetzte Seite zwischenspeichern, da die Antwort mit einer Anweisung "no-cache" gekennzeichnet würde, die diese Einheiten an der Zwischenspeicherung der zusammengesetzten Seite hindern würde. Der dazwischengeschaltete Server 708 würde sowohl das Elternfragment als auch das Kindfragment zwischenspeichern.
Nun Bezug nehmend auf 7B zeigt ein Blockschaltbild einen Teil des Datenflusses zwischen einem Web-Anwendungs-Server und einem Client, um zu veranschaulichen, wie eine Gruppe von Einheiten angewiesen werden kann, Fragmente in einem Cachespeicher zwischenzuspeichern, der sich in nächster Nähe eines Endbenutzers oder einer Client-Einheit befindet. Die Client-Einheit 720 umfasst die Cachespeicher-Verwaltungseinheit 722, die keine Fragmente unterstützt und die eine Anforderung für ein Objekt erzeugt und die Anforderung an den dazwischengeschalteten Server 724 sendet. Die Client-Einheit weiß nicht, dass das angeforderte Objekt tatsächlich ein Fragment ist. Der dazwischengeschaltete Server 724 empfängt die Anforderung; da die Cachespeicher-Verwaltungseinheit 726 zwar Fragmente unterstützt, aber nicht über eine zwischengespeicherte Version des angeforderten Fragments verfügt, fügt die Cachespeicher-Verwaltungseinheit 726 einen Kopfbereich "Fragment: supports-fragments" zu der Anforderung hinzu und leitet die Anforderung an den Zielserver.
Der dazwischengeschaltete Server 728 empfängt die Anforderung; da die Cachespeicher-Verwaltungseinheit 730 nicht über eine zwischengespeicherte Version des angeforderten Fragments verfügt, stellt die Cachespeicher-Verwaltungseinheit 730, die Fragmente unterstützt, sicher, dass in der Anforderungsnachricht ein Kopfbereich "Fragment: supports-fragments" enthalten ist und leitet die Anforderung an den Zielserver. Der dazwischengeschaltete Server 732 enthält die Cachespeicher-Verwaltungseinheit 734, die weder Fragmente unterstützt noch über eine zwischengespeicherte Version des angeforderten Objekts verfügt, und leitet die Anforderung weiter.
Anhand der eingehenden Anforderungsnachricht, die den Kopfbereich "Fragment: supports-fragments" enthält, kann der Web-Anwendungs-Server 736 feststellen, dass eine nachgelagerte Datenverarbeitungseinheit über eine Cachespeicher-Verwaltungseinheit verfügt, die Fragmente unterstützt. Folglich kann der Web-Anwendungs-Server 736 feststellen, dass es angebracht ist, eine Antwort zurückzusenden, die Fragmente enthält. Jedoch kennzeichnet der Web-Anwendungs-Server 736 die Antwortnachricht mit einem Kopfbereich "Cache-Control: private", was zur Folge hat, dass das Fragment in der Antwort nur von dem Cachespeicher zwischengespeichert wird, der Fragmente unterstützt und der sich in nächster Nähe des Endbenutzers oder der Client-Einheit befindet; die Cachespeicher-Verwaltungseinheit 738 speichert das Fragment in der Antwort nicht zwischen.
Der dazwischengeschaltete Server 732 unterstützt keine Fragmente. Die Cachespeicher-Verwaltungseinheit 734 erkennt die Anweisung "private" und speichert das Fragment folglich nicht zwischen, und der dazwischengeschaltete Server 732 leitet die Antwort lediglich weiter. Im Gegensatz dazu unterstützt die Cachespeicher-Verwaltungseinheit 730 Fragmente, erkennt aber, dass die ursprüngliche Anforderung mit einem Kopfbereich "Fragment: supports-fragment" gekennzeichnet war, so dass eine nachgelagerte Einheit das Fragment noch näher am Endbenutzer oder der Client-Einheit zwischenspeichern kann. Daher interpretiert die Cachespeicher-Verwaltungseinheit 730 die Anweisung "private" so, dass sie angewiesen wird, das Fragment in der Antwort nicht zwischenzuspeichern.
Die Cachespeicher-Verwaltungseinheit 726 unterstützt auch Fragmente, erkennt aber, dass die ursprüngliche Anforderung nicht mit einem Kopfbereich "Fragment: supports-fragment" gekennzeichnet war, so dass keine nachgelagerte Einheit das Fragment näher am Endbenutzer oder näher an der Client-Einheit zwischenspeichern kann. Daher interpretiert die Cachespeicher-Verwaltungseinheit 726 die Anweisung "private" so, dass sie angewiesen wird, das Fragment in der Antwort zwischenzuspeichern. Der dazwischengeschaltete Server 724 leitet die Antwort dann an die Client-Einheit 720 weiter; die Cachespeicher-Verwaltungseinheit 722 unterstützt keine Fragmente und interpretiert die Anweisung "private" folglich so, dass sie angewiesen wird, das Fragment nicht zwischenzuspeichern.
Beispiel für Zwischenspeicher, die Fragmente unterstützen und die zur Unterstützung der Zwischenspeicherung von aufgaben- oder kategoriespezifischen Inhalten verwendet werden
Nun Bezug nehmend auf die 8A bis 8D zeigt ein Datenflussdiagramm einen Teil der Verarbeitungsschritte, die in einem Client, einem dazwischengeschalteten Cachespeicher, der Fragmente unterstützt, oder einem Server stattfinden, um zu veranschaulichen, dass die Zwischenspeicherung von dynamischen aufgabenspezifischen oder kategoriespezifischen Inhalten gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung erreicht werden kann. Ein Teil des Web-Inhalts kann so kategorisiert werden, dass er für eine Gruppe von Benutzern spezifisch ist, und zwar aufgrund ihrer Zugehörigkeit zu einer bestimmten Einrichtung oder aufgrund ihrer Rolle oder Aufgabe in einer bestimmten Einrichtung. Beispielsweise kann ein Unternehmen eine Version seiner Preisgestaltungs-Datenbank für seine Produkte gegenüber einer ersten Firma und eine zweite Version seiner Preisgestaltungs-Datenbank für seine Produkte gegenüber einer zweiten Firma veröffentlichen. Die zweite Firma kann zum Beispiel große Volumenrabatte erhalten, wenn sie große Mengen der Produkte des Unternehmens erwirbt.
Wenn ein erster Angestellter der ersten Firma die Website des Unternehmens besucht, sollte dieser Angestellte Webseiten empfangen, die die Preisgestaltungs-Informationen für die erste Firma zeigen. Die Preisgestaltungs-Informationen können sich verhältnismäßig oft ändern, so dass eine Zwischenspeicherung der Preisgestaltungs-Informationen im Vergleich zu statischen Inhalten schwieriger wäre. Wenn ein Angestellter der zweiten Firma die Website des Unternehmens besucht, sollte dieser Angestellte Webseiten empfangen, die die Preisgestaltungs-Informationen für die zweite Firma zeigen.
In der bevorzugten Ausführungsform der vorliegenden Erfindung können die Webseiten, die für die Angestellten der verschiedenen Unternehmenskunden erzeugt wurden, so zwischengespeichert werden, dass sie auch anderen Angestellten derselben Firma zur Verfügung stehen. Wenn ein zweiter Angestellter der ersten Firma die Website des Unternehmens besucht, kann dieser Angestellte die Webseiten empfangen, die für den ersten Angestellten derselben Firma zwischengespeichert wurden. Anders ausgedrückt, der Inhalt der Webseiten des Unternehmens wurde zur Verwendung durch verschiedene Einrichtungen, d. h. die verschiedenen Unternehmenskunden, kategorisiert.
Verwenden wir ein zweites Beispiel, bei dem ein Unternehmen eine Website haben kann, die Informationen über die Mitarbeiter enthält, aber ein Teil der Informationen sollte nur von Führungskräften des Unternehmens eingesehen werden können. Obgleich es sich bei den Informationen für die Führungskräfte um dynamische Inhalte handeln kann, sollte es aber nicht erforderlich sein, mehrere Kopien der für die Führungskräfte vorgesehenen Informationen für jeden leitenden Angestellten zwischenzuspeichern, der die Informationen einsieht. Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung können aufgabenspezifische Inhalte, z. B. Inhalte für Führungskräfte gegenüber Inhalten für Nicht-Führungskräfte, zwischengespeichert werden, und die jeweilige Aufgabe des Benutzers in einem Unternehmen kann bei der Festlegung, welcher Teil des zwischengespeicherten Inhalts an den Benutzer zurückgeschickt wird, hilfreich sein und entsprechend genutzt werden.
Diese Beispiele können mit Hilfe einer Unterscheidung nach Kategorien allgemein beschrieben werden. Das Konzept einer Inhalt-Kategorie kann auf Benutzeraufgaben, institutionelle Einrichtungen usw. angewendet werden, und zwar auf der Grundlage eines Merkmals, das auf einen Benutzer, der auf Inhalte zugreift, angewendet werden kann. Die 8A bis 8D zeigen ein allgemeines Beispiel der Art und Weise, in der die bevorzugte Ausführungsform der vorliegenden Erfindung auf kategoriespezifische Inhalte im Cachespeicher angewendet werden kann.
Bezug nehmend auf 8A erzeugt eine Client-Anwendung, z. B. ein Browser, eine Seitenanforderung (Schritt 802) und sendet sie an einen Anwendungs-Server (Schritt 804). Ein dazwischengeschalteter Cachespeicher, der Fragmente unterstützt, verfügt nicht über eine Kopie der angeforderten Seite und kann folglich auch keine zwischengespeicherte Kopie zurückschicken. Der Anwendungs-Server stellt fest, dass die angeforderte Seite nur von einer bestimmten Benutzerkategorie eingesehen werden darf, erkennt aber, dass der Anforderung kein erforderliches Cookie beigefügt ist, das den Anforderer als der eingeschränkten Benutzerkategorie zugehörig kennzeichnet. Der Server erzeugt eine Seite mit einer Identitätsprüfungs-Zufallszahl (authentication challenge Page) (Schritt 808) und sendet sie an den Client (Schritt 810); die Seite mit der Identitätsprüfungs-Zufallszahl wird als eine Seite gekennzeichnet, die nicht im Zwischenspeicher abgelegt werden kann, so dass der dazwischengeschaltete Cachespeicher sie nicht zwischenspeichert.
Der Client empfängt die Seite mit der Identitätsprüfungs-Zufallszahl und übergibt sie dem Benutzer (Schritt 812), der dann eine Benutzerkennung und ein Passwort bereitstellt (Schritt 814), die an den Server zurückgeschickt werden (Schritt 816). Der Server prüft die Echtheit der Informationen des Benutzers (Schritt 818) und stellt mittels der Benutzerkennung fest, zu welcher Benutzerkategorie der ausgewiesene Benutzer gehört (Schritt 820). Nachdem er eine Benutzerkategorie ermittelt hat, wie zum Beispiel eine Führungsaufgabe, erzeugt der Server ein Kategorie-Cookie, das Informationen enthält, die die Kennzeichnung der ermittelten Benutzerkategorie ermöglichen (Schritt 822). Die ursprünglich angeforderte Seite wird ebenfalls erzeugt (Schritt 824), und die Seite und das Kategorie-Cookie werden an den Client gesendet (Schritt 826).
Bis zu diesem Zeitpunkt hat der dazwischengeschaltete Cachespeicher keine Inhalte zwischengespeichert. Die Seite, die gerade zurückgeschickt wird, ist jedoch als eine Seite gekennzeichnet, die gemäß den Regeln für die Zwischenspeicherung in Cachespeichern, die Fragmente unterstützen, im Zwischenspeicher abgelegt werden kann, so dass der dazwischengeschaltete Cachespeicher die Seite speichert (Schritt 828), wobei er eine Kennung für die Seite, das Kategorie-Cookie, das der Seite beigefügt ist, und andere geeignete Informationen verwendet, zu deren Verwendung der dazwischengeschaltete Cachespeicher in den Regeln zur Zwischenspeicherung von Fragmenten, die mit der Antwortnachricht an den Client einhergehen, aufgefordert wird. Nachdem der Client die angeforderte Seite empfangen hat, wird sie dem Benutzer übergeben (Schritt 830), und das beigefügte Kategorie-Cookie wird von der Client-Anwendung in ihrem Cookie-Cachespeicher gespeichert (Schritt 832).
Bezug nehmend auf 8B ist ein Beispiel für die Aktualisierung eines zuvor ausgegebenen Kategorie-Cookie gezeigt. Eine Client-Anwendung erzeugt eine Seitenanforderung (Schritt 842), die ähnlich der in 8A gezeigten Seitenanforderung ist, beispielsweise von derselben Domäne. Der Benutzer hat jedoch eine Aktion durchgeführt, die bewirkt, dass die Kategorie des Benutzers geändert wird. Zum Beispiel hat der Benutzer möglicherweise Seiten in Bezug auf seine Aufgabe als Vorgesetzter einer bestimmten Gruppe von Angestellten betrachtet, und der Benutzer kann dann entscheiden, Seiten in Bezug auf seine Aufgabe als Leiter der Finanzabteilung einzusehen. Da die Identität des Benutzers zuvor geprüft worden ist, sollte der Server keinen weiteren Identitätsprüfungsprozess durchführen. Der Server sollte aber ein neues Kategorie-Cookie für den Benutzer ausgeben.
Die Seitenanforderung wird mit dem beigefügten Kategorie-Cookie an den Server gesendet (Schritt 844). Der dazwischengeschaltete Cachespeicher verfügt nicht über die angeforderte Seite, so dass ein missglückter Cachespeicher-Zugriff stattfindet. Der Server stellt fest, dass der Client eine Operation anfordert, die einen neuen Wert eines Kategorie-Cookie erfordert (Schritt 846), und gibt ein neues Kategorie-Cookie aus (Schritt 848). Die angeforderte Seite wird auch erzeugt (Schritt 850), und die angeforderte Seite und das neu ausgegebene Kategorie-Cookie werden zurückgeschickt (Schritt 852). Der dazwischengeschaltete Cachespeicher speichert dann die Seite entsprechend dem neuen Wert des Cookie (Schritt 854). Der Client empfangt und übergibt die angeforderte Seite (Schritt 856), und der neue Wert des Cookie wird im Cookie-Cachespeicher am Client gespeichert (Schritt 858). Auf diese Weise wird der dazwischengeschaltete Cachespeicher aktualisiert, wenn das Kategorie-Cookie aktualisiert wird.
Bezug nehmend auf 8C ist ein Beispiel für die Art und Weise gezeigt, in der die fortgesetzte Verwendung desselben Kategorie-Cookie nach wie vor zu einem missglückten Speicherzugriff führen kann. Eine Client-Anwendung erzeugt eine Seitenanforderung (Schritt 862), die mit dem beigefügten Kategorie-Cookie an den Server gesendet wird (Schritt 864). Der dazwischengeschaltete Cachespeicher verfügt nicht über die angeforderte Seite, so dass folglich ein missglückter Speicherzugriff stattfindet. Der Server verwendet den Wert im Kategorie-Cookie, um dynamisch einen bestimmten Inhalts-Typ festzustellen und um eine entsprechende Seite zu erzeugen (Schritt 866), und die erzeugte Seite und das unveränderte Kategorie-Cookie werden zurückgeschickt (Schritt 868). Der dazwischengeschaltete Cachespeicher speichert die Seite (Schritt 870) und leitet sie an den Client weiter. Der Client empfängt und übergibt die angeforderte Seite (Schritt 872); da sich das Kategorie-Cookie nicht verändert hat, wird der Client nicht als ein Client angegeben, der das Kategorie-Cookie im Cookie-Cachespeicher außer Kraft setzt.
Gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung hat der dazwischengeschaltete Cachespeicher in den Schritten 828, 854 und 870 eine Kopie der Seite von der Antwortnachricht gemäß der Regel zur Zwischenspeicherung von Fragmenten, die vom Server in die Antwortnachricht gestellt wurde, gespeichert. Bei der bevorzugten Ausführungsform der vorliegenden Erfindung kann ein Cookie in einer Cachespeicher-Kennungs-Operation verwendet werden, um zwei verschiedene Versionen einer ähnlichen Seite zu unterscheiden, die andernfalls vielleicht als identische Seiten erkannt würden, wenn nur die zu der Seite gehörende URI zum Zweck der Zwischenspeicherung verwendet würde. Von größerer Bedeutung ist, dass eine Seite in Verbindung mit einem Kategorie-Cookie so zwischengespeichert werden kann, dass ein Kategorie-Cookie anschließend bei einem Suchvorgang im Cachespeicher verwendet werden kann, wodurch Cache-Treffer auf der Grundlage von Ähnlichkeiten bei dem bestätigten Kategorie-Cookie festgestellt werden können, wie in 8D gezeigt ist.
Bezug nehmend auf 8D ist ein Beispiel für die Art und Weise gezeigt, in der die Verwendung desselben Kategorie-Cookie durch zwei verschiedene Benutzer dennoch zu einem Cache-Treffer führen kann, wenn verschiedene Benutzer auf eine einzelne Seite zugreifen. In diesem Beispiel greift ein anderer Benutzer auf dieselbe Seite wie der erste Benutzer in dem vorherigen Beispiel zu, das in 8C gezeigt ist. Der zweite Benutzer gehört jedoch zu derselben Benutzerkategorie wie der erste Benutzer. Anders ausgedrückt, die beiden Benutzer können als Benutzer, die zu derselben Benutzerkategorie gehören, oder als Benutzer, denen dieselbe Aufgabe zugewiesen wurde, beschrieben werden. Diese beiden Benutzer können zum Beispiel Führungskräfte sein, die eine firmeninterne Aktennotiz für Führungskräfte einsehen, die dynamische Inhalte enthält, welche speziell auf die Führungskräfte in einer Abteilung zugeschnitten sind, der die beiden Benutzer angehören. Statt die Aktennotiz für jeden leitenden Angestellten zu erzeugen und zwischenzuspeichern, wurde die Aktennotiz zuvor der Aufgabe des leitenden Angestellten zugeordnet. Nachdem der erste leitende Angestellte die Aktennotiz aufgerufen hat, wäre sie zwischengespeichert worden, und spätere Versuche seitens anderer leitender Angestellter in derselben Kategorie, die Aktennotiz abzurufen, würden zu Cache-Treffern führen. Nachfolgende Versuche seitens anderer leitender Angestellten in einer anderen Kategorie, die Aktennotiz aufzurufen, würden zu einem missglückten Cachespeicher-Zugriff führen, da die nachfolgenden leitenden Angestellten über andere Kategorie-Cookies verfügen würden, obgleich die beiden verschiedenen Versionen der Aktennotiz derselben URI zugeordnet sein können.
Eine Client-Anwendung erzeugt eine Seitenanforderung (Schritt 882), die mit dem beigefügten Kategorie-Cookie, das dem zweiten Benutzer gehört, an den Server gesendet wird (Schritt 884). In diesem Fall verfügt der dazwischengeschaltete Cachespeicher über eine Kopie der angeforderten Seite, die von dem URI-Pfad in der Anforderung und dem zugehörigen Kategorie-Cookie ausgewiesen wird, so dass ein Cache-Treffer stattfindet (Schritt 886). Der dazwischengeschaltete Cachespeicher kann die angeforderte Seite sofort zurückschicken, ohne die Anforderung an den Server weiterzuleiten (Schritt 888), und der Client empfängt die angeforderte Seite und übergibt sie dem zweiten Benutzer (Schritt 890).
Auf diese Weise kann der dazwischengeschaltete Cachespeicher tatsächlich mehrere Versionen desselben Fragments speichern, und die passende Version des Fragments wird an einen Benutzer auf der Grundlage seines bestätigten Kategorie-Cookies zurückgeschickt, d. h., nur das Kategorie-Cookie bestimmt, welche Version von verschiedenen Versionen eines ansonsten gleichen Fragments ausgewählt wird. Weitere Beispiele für die Verwendung von Cookies, um Fragmente zu unterscheiden, sind nachstehend aufgeführt, insbesondere mit Bezug auf Kategorien von Käufergruppen.
Verbesserung der Leistungsfähigkeit bei der Verarbeitung von mehreren Fragmenten in einer einzigen Nachricht
Nun Bezug nehmend auf 9A zeigt ein Flussdiagramm einen Prozess, mittels dessen mehrere Fragmente in einer einzigen Anforderungsnachricht angegeben und anschließend verarbeitet werden können. Der in 9A gezeigte Prozess könnte in Verbindung mit dem in 6N gezeigten Prozess oder einem anderen Prozess verwendet werden, bei dem mehrere Fragmente abgerufen werden müssen, insbesondere bevor diese Fragmente zu einem einzigen Fragment zusammengefasst werden.
Nachdem ein Fragment von einer Antwortnachricht oder aus dem Cachespeicher abgerufen wurde, beginnt der Prozess mit der Prüfung der Anweisung "contains-fragments", um festzustellen, ob es ein Blatt-Fragment ist oder andere Fragmente enthält. Wenn es andere Fragmente enthält, wird es zerlegt, um die enthaltenen Fragmente zu finden.
Nachdem die Quellenkennungen für alle Fragmente der nächsten Ebene erfasst worden sind, wird eine einzelne Stapelverarbeitungsanforderung erzeugt (Schritt 904); die Stapelverarbeitungsanforderung kann ein serverseitiges Stapelverarbeitungsprogramm enthalten, das beim Abrufen der Fragmente zu verwenden ist, d. h. ein Servlet. Die Stapelverarbeitungsanforderung enthält alle Quellenkennungen, z. B. URIs, für die Fragmente der nächsten Ebene. Es wird davon ausgegangen, dass der lokale Cachespeicher auf einen Cache-Treffer bei beliebigen dieser Fragmente der nächsten Ebene geprüft wurde; wenn es einen Cache-Treffer bei einem Fragment der nächsten Ebene gab, wird es nicht in die Stapelverarbeitungsanforderung aufgenommen.
Die Stapelverarbeitungsanforderungs-Nachricht wird dann an einen Server gesendet (Schritt 906), und die Cachespeicher-Verwaltungseinheit wartet auf den Empfang einer mehrteiligen MIME-(Multipurpose-Internet-Mail-Extension-)Antwort (Schritt 908). Vorzugsweise wird für die Anforderung ein ausführbares Programmsegment erzeugt, und das Programmsegment befindet sich im Ruhemodus, während es auf eine Antwort wartet und während die Datenverarbeitungseinheit andere Operationen durchführt.
Nach dem Empfang der Antwort durchläuft die Cachespeicher-Verwaltungseinheit jedes Fragment in der Antwort. Aus der mehrteiligen Antwortnachricht wird ein nächstes Fragment abgerufen (Schritt 910) und dann zwischengespeichert (Schritt 912). Anschließend wird festgestellt, ob es in der mehrteiligen Antwortnachricht noch weitere Fragmente gibt, die verarbeitet werden müssen (Schritt 914), und wenn ja, verzweigt der Prozess zum Schritt 910 zurück, um ein weiteres Fragment zu verarbeiten. Andernfalls können die neu empfangenen Fragmente zerlegt oder geprüft werden, um festzustellen, ob diese Fragmente Verknüpfungen zu Fragmenten der nächsten Ebene enthalten (Schritt 916), und wenn ja, verzweigt der Prozess zum Schritt 902 zurück, um bei Bedarf weitere Fragmente in einer Stapelverarbeitungsanforderung anzufordern. Andernfalls werden die neu empfangenen Fragmente in Seitenzusammensetzungsoperationen zusammengefasst (Schritt 918), und der Prozess ist beendet.
Nun Bezug nehmend auf 9B zeigt ein Flussdiagramm einen Prozess, mittels dessen eine einzelne Anforderungsnachricht an einer dazwischengeschalteten Cachespeicher-Verwaltungseinheit empfangen und anschließend verarbeitet werden kann. Der in 9B gezeigte Prozess könnte in Verbindung mit dem in 6V gezeigten Prozess oder einem anderen Prozess verwendet werden, bei dem eine Anforderungsnachricht an einem dazwischengeschalteten Cachespeicher verarbeitet wird.
Der Prozess beginnt, wenn eine Stapelverarbeitungsanforderung an einem dazwischengeschalteten Cachespeicher, der Fragmente unterstützt, empfangen wird (Schritt 922). Die Gruppe der Quellenkennungen in der Stapelverarbeitungsanforderung wird dann in einer Schleife verarbeitet. Die nächste Quellenkennung für eines der angeforderten Fragmente wird von der Anforderungsnachricht abgerufen (Schritt 924), und es wird festgestellt, ob in dem lokalen Cachespeicher ein Cache-Treffer stattgefunden hat (Schritt 926). Wenn es einen Cache-Treffer gibt, kann der nächste Schritt übersprungen werden, und die Quellenkennung kann aus der Stapelverarbeitungsanforderungs-Nachricht entfernt werden (Schritt 928). Es wird festgestellt, ob es in der Stapelverarbeitungsanforderungs-Nachricht noch weitere Quellenkennungen gibt, die verarbeitet werden müssen (Schritt 930), und wenn ja, verzweigt der Prozess zum Schritt 924 zurück, um eine weitere Quellenkennung zu verarbeiten.
Es wird auch festgestellt, ob alle angeforderten Fragmente in dem lokalen Cachespeicher gefunden wurden (Schritt 932). Wenn ja, besteht keine Notwendigkeit, die Stapelverarbeitungsanforderung weiterzuleiten, und der Prozess verzweigt, um eine Antwortnachricht zu erstellen. Wenn es mindestens einen missglückten Cachespeicherzugriff gab, wird die geänderte Stapelverarbeitungsanforderung mit der entfernten Quellenkennung (oder Quellenkennungen) an den Server weitergeleitet (Schritt 934). Alternativ dazu könnte die Stapelverarbeitungsanforderung in eine gewöhnliche Anforderungsnachricht geändert werden, wenn eine einzige Quellenkennung übrig bleibt. Die Cachespeicher-Verwaltungseinheit wartet auf den Empfang einer mehrteiligen MIME-Antwort (Schritt 936); vorzugsweise wird für die Anforderung ein Programmsegment erzeugt, und das Programmsegment befindet sich im Ruhemodus, während es auf eine Antwort wartet und während die Datenverarbeitungseinheit andere Operationen durchführt.
Nach dem Empfang der Antwort durchläuft die Cachespeicher-Verwaltungseinheit jedes Fragment in der Antwort. Von der mehrteiligen Antwortnachricht wird ein nächstes Fragment abgerufen (Schritt 938) und dann zwischengespeichert (Schritt 940), wobei davon ausgegangen wird, dass es angebracht ist, das Fragment im lokalen Cachespeicher zwischenzuspeichern. Anschließend wird festgestellt, ob es in der mehrteiligen Antwortnachricht noch weitere Fragmente gibt, die verarbeitet werden müssen (Schritt 942), und wenn ja, verzweigt der Prozess zum Schritt 938 zurück, um ein weiteres Fragment zu verarbeiten. Es wird angenommen, dass die neu empfangenen Fragmente nicht zerlegt oder geprüft werden, um festzustellen, ob diese Fragmente Verknüpfungen zu Fragmenten der nächsten Ebene enthalten, da davon ausgegangen werden kann, dass dieser Prozess an der Cachespeicher-Verwaltungseinheit durchgeführt wird, die die ursprüngliche Stapelverarbeitungsanforderung erzeugt hat; alternativ dazu könnte dieser Prozess an der aktuellen Cachespeicher-Verwaltungseinheit in einer ähnlichen Weise wie der in 9A beschriebenen durchgeführt werden. In jedem Fall wird mit den Fragmenten, die den Quellenkennungen entsprechen, welche in der ursprünglichen Stapelverarbeitungsanforderung empfangen worden sind (Schritt 944), eine mehrteilige MIME-Antwort erzeugt und zurückgeschickt (Schritt 946), wodurch der Prozess abgeschlossen wird.
Nun Bezug nehmend auf 9C zeigt ein Flussdiagramm einen Prozess an einem Web-Anwendungs-Server, der zur Verarbeitung einer Stapelverarbeitungsanforderungs-Nachricht für mehrere Fragmente dient. Der in 9C gezeigte Prozess könnte durchgeführt werden, nachdem eine Stapelverarbeitungsanforderungs-Nachricht mehrere Datenverarbeitungseinheiten mit Cachespeicher-Verwaltungseinheiten, die Fragmente unterstützen und die die Fragmentanforderungen nicht erfüllen konnten, durchlaufen hat, d. h., an mehreren Einheiten fanden möglicherweise missglückte Cachespeicherzugriffe statt.
Der Prozess beginnt mit dem Empfang einer Stapelverarbeitungsanforderung an einem Server (Schritt 952); die Stapelverarbeitungsanforderung enthält mehrere Fragmentanforderungen, die dann der Reihe nach verarbeitet werden. Eine nächste Fragmentanforderung wird von der Stapelverarbeitungsanforderungs-Nachricht abgerufen (Schritt 954) und ausgeführt (Schritt 956), wobei dies voraussichtlich die Erzeugung des Fragments beinhaltet, woraufhin das Fragment zur Übertragung gegebenenfalls optional formatiert oder mit einer semantischen Auszeichnung versehen werden muss (Schritt 958), obgleich es möglich ist, dass das Fragment zuvor am Server zwischengespeichert worden war. Es wird festgestellt, ob es in der Stapelverarbeitungsanforderungs-Nachricht noch eine weitere Fragmentanforderung gibt (Schritt 960), und wenn ja, verzweigt der Prozess, um eine weitere Fragmentanforderung zu verarbeiten. Andernfalls wird eine mehrteilige MIME-Antwortnachricht mit allen angeforderten Fragmenten erzeugt (Schritt 962), und die Antwortnachricht wird zurückgeschickt, wodurch der Prozess abgeschlossen wird.
Beispiele für eine Verringerung der Größe des Cachespeichers
Nun Bezug nehmend auf die 10A bis 10D sind mehrere Beispiele gezeigt, um die vorteilhafte Verringerung der Größe des Cachespeichers zu veranschaulichen, die sich mit der bevorzugten Ausführungsform der vorliegenden Erfindung erzielen lässt. Ein Kriterium für die Auswahl dessen, aus dem ein Fragment in einer bestimmten Anwendung besteht, ist die Häufigkeit, mit der ein Teil des Inhalts über verschiedene Seiten gemeinsam benutzt wird. Wenn ein Teil des Inhalts in hohem Maße gemeinsam benutzt wird und man diesen Teil des Inhalts zu einem Fragment macht, kann man die Größe des Cachespeichers stark berücksichtigen, da die Möglichkeit besteht, das Fragment einmal zu speichern, statt es auf vielen Seiten zu wiederholen. Folglich ermöglichen Fragmente eine Form der Verdichtung über viele Seiten hinweg, um die Größe des Cachespeichers zu verringern. Der Vorteil dieser Verdichtung kann als eine Kostensenkung betrachtet werden, z. B. kann die Größe des Cachespeichers für eine feste Trefferquote oder zur Verbesserung der Leistungsfähigkeit verringert werden oder die Trefferquote einer festen Cachespeicher-Größe kann erhöht werden, wobei diese Möglichkeiten auch kombiniert werden können. Die 10A bis 10D zeigen verschiedene Nutzungsszenarien für die bevorzugte Ausführungsform der vorliegenden Erfindung sowie die Verringerungen der Cachespeicher-Größe, die im Vergleich zu gleichwertigen Szenarien nach dem Stand der Technik erreicht werden können.
Bezug nehmend auf 10A ist ein Szenario mit gemeinsam benutzter Seitenleiste gezeigt. Jede Seite umfasst Teile der Seitenleiste und andere Teile der Seite; nach dem Stand der Technik wird jede Seite als eine vollständige Seite mit allen untergeordneten Objekten in einem Cachespeicher gespeichert, der keine Fragmente unterstützt. Bei der bevorzugten Ausführungsform der vorliegenden Erfindung wurde jede Seite so zusammengestellt, dass sie ein Seitenleisten-Fragment und ein Fragment in Form von der restlichen Seite enthält, die alle in einem Cachespeicher gespeichert werden, der Fragmente unterstützt. Wie bei der bevorzugten Ausführungsform der vorliegenden Erfindung zu erkennen ist, wird das Seitenleisten-Fragment nur einmal gespeichert. Anders ausgedrückt, alle Seiten auf einer bestimmten Site benutzen dasselbe Seitenleisten-Fragment gemeinsam. Wenn die Seitenleiste 20% einer jeden Seite in Anspruch nimmt, kann man, wenn man sie aus allen Seiten ausklammert, die Größe des Cachespeichers um ungefähr 20% verringern, da die Seitenleiste nicht repliziert wird.
Bezug nehmend auf 10B ist ein Szenario mit einer Käufergruppe gezeigt. Eine Seite mit der Produktbeschreibung hat einen anderen Preis für jede Käufergruppe, aber der Rest der Produktbeschreibung ist von der Käufergruppe unabhängig. Nach dem Stand der Technik gibt es eine Produktseite für jede Kombination aus Produkt und Käufergruppe, wobei jede dieser Produktseiten möglicherweise in einem Cachespeicher gespeichert werden könnte, der keine Fragmente unterstützt. Im Gegensatz dazu muss ein Cachespeicher, der Fragmente gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung unterstützt, nur das Preisdaten-Fragment für die Kombination aus Produkt und Gruppe und das Produktbeschreibungs-Fragment speichern und braucht nicht alle der ganzen Seitenkombinationen zu speichern.
Die möglichen Einsparungen an Speicherplatz können wie folgt näherungsweise ermittelt werden. Jeder Preis hat eine Größe von 100 Byte (s1) und der Rest der Produktbeschreibung hat eine Größe von 10 KByte (s2). Es gibt 10.000 Produkte (p) und 5 Käufergruppen (g). Wenn man die vollständig erweiterten Seiten speichert, gibt es möglicherweise (10.000 × 5) = 50.000 (p·g) Elemente insgesamt mit einer Größe von ca. jeweils 10 KByte (s2 ist ungefähr gleich s1 + s2), was eine Gesamtgröße von ca. 500.000 KByte (p·g·s2) ergibt. Wenn man stattdessen die Preise in Fragmenten speichert, die vom Rest der Produktbeschreibung getrennt sind, gibt es 10.000 (p) Produktfragmente im Cachespeicher mit einer Größe von jeweils 10 KByte (s2), was eine Größe von 100.000 KByte (p·s2) ergibt, plus 10.000 × 5 = 50.000 (p·g) Preise mit einer Größe von jeweils 10 Byte (s1), was eine Größe von 5.000 KByte ergibt. Die gesamte Größe der Fragmente ist die Summe daraus oder 105.000 KByte. Wenn man einen Cachespeicher einsetzt, der Fragmente unterstützt, stellt dies eine nahezu fünffache Verringerung der Größe des Cachespeichers dar.
Bezug nehmend auf 10C ist ein Personalisierungsszenario gezeigt. Eine Seite mit der Produktbeschreibung enthält einen Personalisierungsteil, und es gibt 10.000 Produkte (p) und 100.000 Benutzer (u). Nach dem Stand der Technik, wenn man die vollständig erweiterten Seiten speichert, gibt es potenziell 10.000 × 100.000 = 1.000.000 (u·p) Elemente insgesamt im Cachespeicher.
Im Gegensatz dazu kann man bei einem Cachespeicher, der Fragmente unterstützt und gemäß der bevorzugten Ausführungsform der vorliegenden Erfindung realisiert wird, die Seiten als getrennte Fragmente speichern. In diesem Fall gibt es nur 10.000 + 100.000 = 110.000 (u + p) Elemente insgesamt im Cachespeicher, und jedes Element ist kleiner. Dies stellt eine ungefähr 20.000-fache Verringerung der Größe des Cachespeichers dar.
Fahren wir mit demselben Beispiel fort. Ein Auszeichnungselement FRAGMENTLINK, dessen SRC-Attribut ein Cookie, z. B. src="cookie://{cookie name}" oder einen URI-Abfrageparameter, z. B. src="parm://{parm name}", angibt, kann verwendet werden, um den Wert dieses Cookie oder dieses Abfrageparameters zu ersetzen. Wenn die Personalisierung so klein wäre, dass sie von einem Cookie-Wert dargestellt werden könnte, könnte in diesem Szenario mit dem Ersatz dieser Variablen der zusätzliche Aufwand in Form von der Anforderung eines Personalisierungsfragments von einem Web-Anwendungs-Server und dessen Zwischenspeicherung vermieden werden. Beispielsweise könnte eine Begrüßung wie "Hallo John Smith. Willkommen in unserem Ladengeschäft!!!" mit einem Cookie, dessen Name "userName" lautet und dessen Wert "John Smith" ist, mit der folgenden HTML-Anweisung vorgenommen werden:

Hallo, {fragmentlink src="cookie://userName"). Willkommen in unserem Ladengeschäft!!
Bezug nehmend auf 10D ist ein Szenario mit einer Aktien-Beobachtungsliste gezeigt; Aktien-Beobachtungslisten sind in vielen Web-Portalen verfügbar. Eine Seite enthält eine personalisierte Liste mit Aktienkursen. Dieses Szenario ist ähnlich dem Personalisierungsszenario, außer dass die benutzerspezifischen Informationen zu dem Fragment der obersten Ebene statt zu dem enthaltenen Fragment gehören. Jeder Benutzer hat eine eigene Liste mit Aktien, aber jede Aktie wird von vielen Benutzerlisten gemeinsam verwendet. Es gibt 100.000 Benutzer (u) und 1.000 Aktien (s). Jede Benutzerbeschreibung hat eine Größe von 1 KByte (s1), und jeder Aktienkurs hat eine Größe von 100 Byte (s2). Die Benutzer haben durchschnittlich 10 Aktien in ihrer Liste (1). Wenn man die vollständig erweiterten Seiten speichert, hat der Cachespeicher eine Größe von 100.000·1 KByte = 100.000 KByte (u·s1) plus 100.000·10·100 Byte = 100.000 KByte (u·1·s2), was insgesamt 200.000 KByte ergibt. Wenn man die einzelnen Aktienkurse als getrennte Fragmente speichert, hat der Cachespeicher eine Größe von 100.000 × 1 KByte = 100.000 KByte (u·s1) für die benutzerspezifischen Fragmente plus 1.000·100 Byte = 100 KByte (s·s2) für die Aktienkurs-Fragmente, was insgesamt 100.100 KByte ergibt. Dies stellt ungefähr eine zweifache Verringerung der Größe des Cachespeichers dar, da Aktienkurse nicht repliziert werden.
Das Szenario mit der Aktien-Beobachtungsliste kann noch weiter verbessert werden, indem man das FOREACH-Merkmal von Fragmenten nutzt. In diesem Fall werden alle benutzerspezifischen Fragmente entfernt. Dies ist auch in 10D gezeigt. Das Merkmal FOREACH gibt ein Cookie an, dessen Wert eine Liste fester Länge mit Namen-Wert-Paaren ist, die durch "_" getrennt sind. Für jedes Namen-Wert-Paar wird ein Fragment erzeugt, wobei das Namen-Wert-Paar als URI-Abfrageparameter hinzugefügt wird. In diesem Szenario hätte ein Cookie mit der Bezeichnung "stocks" ("Aktien") eine Liste mit Aktiensymbol-Parametern als Wert, z. B. "symbol=IBM symbol=CSCO symbol=DELL". Dies würde drei Fragmente erzeugen, eines für jedes Aktiensymbol in dem Cookie. Die Größe des Cachespeichers wäre 1 KByte (s1) für das einzelne Fragment in Form von der nicht benutzerspezifischen Schablone plus 100 KByte (s·s2) für die Fragmente in Form von den Aktienkursen, was insgesamt 101 KByte ergibt. Dies stellt eine ungefähr tausendfache Verringerung der Größe dar, da die Fragmente in Form von den benutzerspezifischen Aktienlisten durch ein einziges Aktienlisten-Fragment ersetzt werden.
Die bevorzugte Ausführungsform der vorliegenden Erfindung verringert auch den Arbeitsaufwand, der zur Verwaltung des Inhalts des Cachespeichers notwendig ist. Ein Kriterium für die Auswahl dessen, was ein Fragment in einer bestimmten Anwendung darstellt, ist die Häufigkeit, mit der sich ein Teil des Inhalts ändert. Wenn sich der Inhalt zu oft ändert, als dass er jedes Mal manuell veröffentlicht werden könnte, verwenden Anwendungen üblicherweise eine Schablone, z. B. eine JSP-Schablone, die auf eine Datenbank zugreift, um den Inhalt zu erzeugen, sowie einen Mechanismus, um den Inhalt automatisch ungültig zu machen, wenn sich der Inhalt der Datenbank ändert oder wenn eine Zeitschranke abläuft. Diese Vorgehensweise bei dynamischen Inhalten nimmt den Menschen aus der Schleife heraus und ermöglicht häufige Aktualisierungen.
Derzeit speichern die meisten Cachespeicher keine Anforderungen zwischen, die Abfrageparameter haben, da dies gewöhnlich ein Hinweis auf einen dynamischen Inhalt ist. Ein dynamischer Inhalt kommt jedoch oftmals gut für eine Zwischenspeicherung in Frage. Obgleich sich der Inhalt mit einer bestimmten Rate ändert (ein Preis kann sich zum Beispiel wöchentlich ändern, die Ausgabe- beziehungsweise Rücknahmepreise von Investmentfonds ändern sich täglich, die Kurse von Aktien ändern sich alle paar Minuten), kann es eine große Zahl von Cache-Treffern zwischen Änderungen geben, so dass sich mit der Zwischenspeicherung immer noch deutliche Verbesserungen bei der Leistungsfähigkeit erzielen lassen.
Wenn sich der Inhalt schnell ändern kann, wird es wichtig, den durch jede Änderung verursachten Arbeitsaufwand zu verringern. Wenn man eine Seite in Fragmente gliedert, ermöglicht dies eine schrittweise Erzeugung des Inhalts. Wenn eine Änderung eintritt, müssen nur diejenigen Teile von nur denjenigen Seiten erneut erzeugt werden, die direkt von der Änderung betroffen sind. Wenn sich ein Teil des Inhalts schnell ändert, könnte aus ihm ein getrenntes Fragment gemacht werden.
Nochmals Bezug nehmend auf das in 10A gezeigte Szenario mit der Seitenleiste, enthält die Seitenleiste Inhalte, die sich alle paar Minuten ändern, z. B. neue Schlagzeilen. Wenn die vollständig erweiterten Seiten gespeichert werden, müssten alle Seiten erneut erzeugt und ausgetauscht werden, wenn sich die Seitenleiste ändert. Wenn die Seitenleiste stattdessen ein getrenntes Fragment ist, muss nur ein Fragment erzeugt und ausgetauscht werden, wenn sich die Seitenleiste ändert.
Nochmals Bezug nehmend auf das in 10B gezeigte Szenario mit der Käufergruppe könnten sich die Preise für die Käufergruppe auf der Grundlage des Umsatzvolumens in der Käufergruppe jede Minute ändern. Wenn die vollständig erweiterten Seiten gespeichert werden, müssten jede Minute alle 50.000 Seiten erzeugt werden. Dazu müssten 500.000 KByte an Cachespeicherkapazität erzeugt und jede Minute ausgetauscht werden. Wenn die Preise stattdessen als getrennte Fragmente gespeichert würden, würden immer noch 50.000 Fragmente erzeugt und ausgetauscht werden, aber es würde nur eine Cachespeicherkapazität von 5.000 KByte erzeugt und ausgetauscht werden. Dies stellt eine hundertfache Verringerung der benötigten Bandbreite dar. Wenn sich ein Aspekt einer Produktbeschreibung, bei dem es sich nicht um einen Preis handelt, geändert hat, müsste anstelle von fünf Seiten nur ein Fragment erzeugt und ausgetauscht werden. Dies stellt eine fünffache Verringerung der Bandbreite dar.
Nochmals Bezug nehmend auf das Personalisierungsszenario in 10C könnte sich ein Produkt alle paar Sekunden ändern, und eine benutzerspezifische Personalisierung könnte sich jeden Tag ändern. Wenn die erweiterten Seiten zwischengespeichert würden, hätte jede Produktänderung zur Folge, dass alle 100.000 Seiten für dieses Produkt erzeugt und ausgetauscht werden müssten, und jede Änderung bei der Personalisierung hätte zur Folge, dass alle 10.000 Seiten für diesen Benutzer erzeugt und ausgetauscht werden müssten. Wenn die Produktbeschreibung und die Personalisierung stattdessen in getrennten Fragmenten gespeichert würden, müsste bei jeder Produktänderung nur ein Fragment erzeugt und ausgetauscht werden (eine 100.000-fache Verbesserung), und bei jeder Änderung der Personalisierung müsste nur ein Fragment erzeugt und ausgetauscht werden (eine 10.000-fache Verbesserung).
Nochmals Bezug nehmend auf das in 10D gezeigte Szenario mit der Aktien-Beobachtungsliste könnten sich die Aktienkurse alle 20 Sekunden ändern. Wenn die erweiterten Seiten im Cachespeicher gespeichert werden, müssen alle 100.000 Benutzerseiten (100.000 KByte) alle 20 Sekunden erzeugt werden. Wenn die Aktien dagegen als getrennte Fragmente gespeichert werden, müssen nur die 1.000 Aktienfragmente (100 KByte) alle 20 Sekunden erzeugt und ausgetauscht werden. Dies stellt eine über 1.000-fache Verbesserung der Bandbreite dar. Wenn eine Aktien-Beobachtungsliste eines einzigen Benutzers geändert wird, wenn der Benutzer zum Beispiel eine Aktie in seine Beobachtungsliste aufnimmt oder aus ihr entfernt, müsste sowohl in dem einen als auch in dem anderen Fall nur ein Fragment erzeugt und ausgetauscht werden.
Beispiele für die Erzeugung und Verwendung von Cachespeicher-Kennungen für Fragmente
Wie vorstehend beschrieben wurde, werden jedem Fragment Zwischenspeicherungs-Informationen zugeordnet, die Cachespeicher anweisen, wie dieses Fragment zwischengespeichert werden soll. Bei statischen Inhalten werden die Zwischenspeicherungs-Informationen jedem Fragment zugeordnet. Dynamische Inhalte werden von einer Schablone oder einem Programm (JSP, CGI usw.) erzeugt, und Zwischenspeicherungs-Informationen würden dieser Schablone zugeordnet werden. Dies könnten gleich bleibende Informationen sein, so dass alle von der Schablone erzeugten Fragmente dieselben Werte hätten. Alternativ dazu könnte die Schablone Code enthalten, der die Zwischenspeicherungs-Informationen festlegt, so dass sie auf der Grundlage irgendeines Algorithmus bei jedem erzeugten Fragment anders sein könnten. In beiden Fällen hat ein bestimmtes Fragment gleich bleibende Werte.
Ein Fragment kann als ein Teil des Inhalts definiert werden, der zum Zweck der Zusammenfassung mit einem anderen Teil des Inhalts begrenzt wurde. In der bevorzugten Ausführungsform der vorliegenden Erfindung wird ein standardisiertes Verfahren zur Benennung von Fragmenten eingesetzt; das Verfahren erzeugt Cachespeicher-Kennungen gemäß einem Verfahren, das vorstehend formaler beschrieben wurde. Dieser Abschnitt beschreibt die Verwendung von Cachespeicher-Kennungen mittels mehreren nachstehend aufgeführten Beispielen, wobei zunächst jedoch die Bildung und die Festlegung von Cachespeicher-Kennungen nochmals kurz beschrieben werden.
Ein Cachespeicher speichert das Fragment, wobei er in einer bestimmten Art und Weise eine Cachespeicher-Kennung verwendet. In die Cachespeicher-Kennung sollten ausreichend Informationen aufgenommen werden, um sie unter allen Anwendungen, die den Cachespeicher nutzen, eindeutig zu machen. Eine Produktkennung allein könnte beispielsweise völlig mit der Produktkennung eines anderen Ladengeschäfts oder mit etwas anderem kollidieren. Da sich der URI-Pfad für ein Fragment für gewöhnlich zumindest teilweise mit demselben Namensabgrenzungsproblem auseinandersetzen muss, ist es zweckmäßig, den URI-Pfad als Teil der Cachespeicher-Kennung für ein Fragment aufzunehmen.
Der Informationsgehalt einer Cachespeicher-Kennung legt fest, in welchem Umfang das Fragment gemeinsam genutzt wird, wie in den folgenden Beispielen gezeigt ist.

(A) Wenn eine Benutzerkennung in einer Cachespeicher-Kennung enthalten ist, wird das Fragment nur für diesen Benutzer verwendet.
(B) Wenn die Kennung einer Käufergruppe in einer Cachespeicher-Kennung enthalten ist, wird das Fragment von allen Mitgliedern dieser Käufergruppe gemeinsam benutzt.
(C) Wenn keine Benutzerkennung oder Kennung einer Käufergruppe in einer Cachespeicher-Kennung enthalten ist, wird das Fragment von allen Benutzern gemeinsam benutzt.

Ein Entwickler einer Web-Anwendung kann den Informationsgehalt einer Cachespeicher-Kennung durch eine Regel im HTTP-FRAGMENT-Kopfbereich des Fragments mit einer Anweisung CACHID festlegen, die angibt, was in die Cachespeicher-Kennung des Fragments aufgenommen wird. Eine Regel ermöglicht es, jeden URI-Abfrageparameter oder jedes Cookie an den URI-Pfad anzufügen und gestattet auch die Verwendung der vollständigen URI (einschließlich Abfrageparametern). Wenn keine Regel vorhanden ist, bedeutet dies, dass keine Zwischenspeicherung stattfinden soll. Wenn mehrere Regeln verwendet werden, werden die Regeln in der Reihenfolge ihres Erscheinens ausprobiert. Die erste Regel, die funktioniert, legt die Cachespeicher-Kennung fest. Wenn keine Regel funktioniert, wird das Fragment nicht zwischengespeichert. Wenn in der Cachespeicher-Kennung ein Abfrageparameter oder ein Cookie enthalten ist, kann er beziehungsweise es entweder erforderlich oder aber optional sein, was im Folgenden beschrieben ist.

(A) Ein Abfrageparameter, der notwendig, aber in der Elternanforderung nicht vorhanden ist, führt dazu, dass die Regel fehlschlägt.
(B) Ein Cookie, das notwendig, aber in der Elternanforderung oder im Ergebnis nicht vorhanden ist, führt dazu, dass die Regel fehlschlägt.
(C) Ein optionaler Abfrageparameter oder ein optionales Cookie, der beziehungsweise das nicht vorhanden ist, wird nicht in die Cachespeicher-Kennung aufgenommen.

Bei einer Cachespeicher-Kennung muss mit Ausnahme von denjenigen Teilen, bei denen ein Standard festgelegt hat, dass bei ihnen nicht nach Groß- und Kleinschreibung unterschieden werden muss, nach Groß- und Kleinschreibung unterschieden werden. Die HTTP-Spezifikation legt fest, dass bei dem Protokoll und bei dem Namen des Hostrechners einer URI nicht nach Groß- und Kleinschreibung unterschieden werden muss, während beim Rest der URI einschließlich der Namen von Abfrageparametern nach Groß- und Kleinschreibung unterschieden werden muss. Gemäß der Spezifikation "HTTP State Management Mechanism", RFC 2109, Internet Engineering Task Force, Februar 1997, muss bei Namen von Cookies nach Groß- und Kleinschreibung unterschieden werden. Bei der Realisierung eines Cachespeichers kann dies ohne Weiteres durchgesetzt werden, indem die Teile, bei denen nicht nach Groß- und Kleinschreibung unterschieden werden muss, in eine einheitliche Groß-/Kleinschreibung überführt werden. Das Verfahren zur Zwischenspeicherung von Fragmenten der bevorzugten Ausführungsform der vorliegenden Erfindung unterscheidet vorzugsweise bei Werten von Abfrageparametern und bei Werten von Cookies nach Groß-/Kleinschreibung.
Nun Bezug nehmend auf die 11A bis 11H wird die Art und Weise, in der das Verfahren der bevorzugten Ausführungsform der vorliegenden Erfindung eindeutige Cachespeicher-Kennungen erstellt und verwendet, um Fragmente zu verarbeiten und zu speichern, mittels mehrerer Übersichtsdarstellungen veranschaulicht.
Mit Bezug auf 11A enthalten alle Elternfragmente auf einer Site dasselbe Seitenleisten-Kindfragment. Mit Ausnahme der Aussage, dass alle Elternfragmente dasselbe Seitenleisten-Fragment enthalten, wird das Elternfragment in diesem Szenario nicht näher angegeben, so dass wir uns hier nur mit dem Kindfragment beschäftigen. Das Kindfragment wird durch seine URI logisch klassifiziert. Da sein Inhalt statisch ist, besteht seine Cachespeicher-Kennung aus der vollständigen URI. Die Regel für die Cachespeicher-Kennung würde lauten:

Fragment: cacheid="URI"
Anders ausgedrückt, die Cachespeicher-Kennung ist die vollständige URI einschließlich aller Abfrageparameter. Ein Beispiel für die Cachespeicher-Kennung wäre:

http://www.acmeStore.com/sidebar.html
Bezug nehmend auf 11B enthält eine Produktbeschreibungsseite keine eingebetteten oder Kindfragmente, d. h., die Seite ist das einzige Fragment. Es wird durch die Produktkennung (productID) logisch klassifiziert. Die Seiten-URI hat einen Abfrageparameter "productID". Die Seitenanforderung hat ein Cookie mit einer verschlüsselten Benutzerkennung (userID), das vom Web-Anwendungs-Server während der Anmeldung erzeugt wurde. Das Cookie "userID" ermöglicht die Zuordnung eines benutzerspezifischen Zustands (Einkaufswagen, Benutzerprofil usw.) zu dem Benutzer. Die userID wird als Cookie und nicht als Abfrageparameter verwendet, da sie mit nahezu jeder Anforderung verwendet werden kann, und es wäre für den Entwickler der Web-Anwendung mühsam, sie in jede Verknüpfung zu stellen. Die Regel für die einzige Cachespeicher-Kennung für die Produktseite könnte die vollständige URI als Cachespeicher-Kennung verwenden, die den Abfrageparameter "productID" enthält, so dass sie mit den richtigen Klassifizierungen zwischengespeichert werden kann. Bei dieser Seite mit dem einzelnen Fragment kann die Cachespeicher-Kennung ihre URI sein. Die Regel für die Cachespeicher-Kennung würde lauten:

Fragment: cacheid="URI"
Anders ausgedrückt, die Cachespeicher-Kennung ist die vollständige URI einschließlich aller Abfrageparameter. Ein Beispiel für die Cachespeicher-Kennung wäre:

http://www.acmeStore.com/productDesc.jsp?productID=AT13394
Eine weitere Möglichkeit, die Cachespeicher-Kennung für dieses Fragment der obersten Ebene anzugeben, ist, die von dem Händler verwendete Produktkennung, z. B. AT13394, bei der es sich um einen URI-Abfrageparameter handelt, sowie den gleich bleibenden URI-Pad zu verwenden, um die Eindeutigkeit sicherzustellen, z. B. http://www.acmeStore.com/productDesc. In diesem Fall würde die Regel für die Cachespeicher-Kennung lauten:

Fragment: cacheid="(producId)"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad; und
(B) dem Namen und dem Wert des Abfrageparameters "productID".

Das Nichtvorhandensein von eckigen Klammern in der Regel ist ein Hinweis darauf, dass der Abfrageparameter "productID" vorhanden sein dürfte. Andernfalls schlägt die Regel fehl, und das Fragment wird nicht zwischengespeichert. Ein Beispiel für die Cachespeicher-Kennung wäre:
http://www.acmeStore.com/productDesc.jsp_productID=AT13394
Es sei nochmals angemerkt, dass der Entwickler der Web-Anwendung nur den Informationsgehalt einer Cachespeicher-Kennung, nicht aber das genaue Format festlegt. Die jeweiligen Arten der Ausführung des Cachespeichers können ihre eigene Art und Weise wählen, in der der festgelegte Informationsgehalt in der Cachespeicher-Kennung codiert wird. Das vorstehende Beispiel verwendet eine einfache Verknüpfung mit einem Unterstrich ("_") als Trennzeichen. Der Entwickler der Web-Anwendung braucht diese Codierung nicht zu kennen.
Bezug nehmend auf 11C ist eine Erweiterung des Szenarios mit der Produktbeschreibung gezeigt. Der Preis wird nun von der Käufergruppe bestimmt, zu der der Benutzer gehört, aber der Rest der Produktbeschreibung ist von der Käufergruppe unabhängig. Ein Produktbeschreibungs-Elternfragment enthält ein Preis-Kindfragment. Das Elternfragment wird durch die productID logisch klassifiziert. Das Kindfragment wird durch die productID und die Gruppenkennung (groupID) logisch klassifiziert. Die Seiten-URI hat einen Abfrageparameter "productID". Die Seitenanforderung hat verschlüsselte Cookies für die Benutzerkennung (userID) und die Gruppenkennung (groupID). Das Cookie "groupID" wird von der Web-Anwendung während der Anmeldung auf der Grundlage des Benutzerprofils erzeugt. Die groupID wird zu einem Cookie und nicht zu einem Abfrageparameter gemacht, da sie mit nahezu jeder Anforderung verwendet werden kann, und es wäre für den Entwickler der Web-Anwendung mühsam, sie in jede Verknüpfung zu stellen.
Der Preis sollte sich in einem gesonderten Kindfragment befinden, das vom Elternfragment aufgenommen wird. Die Regel für die einzige Cachespeicher-Kennung für das Elternfragment wäre die gleiche wie in dem Szenario mit der Produktanzeige. Die Regel für die einzige Cachespeicher-Kennung für das Kindfragment würde den URI-Pfad zusammen mit dem Abfrageparameter "productID" und dem Cookie "groupID" verwenden, so dass sie mit den richtigen Klassifizierungen zwischengespeichert werden kann. Es sei angemerkt, dass die Cachespeicher-Kennung keine Benutzerkennung enthält, da das Fragment sonst nur von einem einzigen Benutzer statt von allen Benutzern, die zu derselben Käufergruppe gehören, verwendet werden könnte, was einen viel größeren Cachespeicher und einen höheren Arbeitsaufwand zur Folge hätte, um den Inhalt des Cachespeichers stets auf dem aktuellen Stand zu halten. Die Regel für die Cachespeicher-Kennung würde lauten:

Fragment: cacheid="(productID, [groupID])"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad;
(B) dem Namen und dem Wert des Abfrageparameters "productID"; und
(C) dem Namen und dem Wert des Cookie "groupID", sofern es in der Anforderung vorhanden ist.

Ein Komma trennt die URI-Abfrageparameter von Cookies. Die eckigen Klammern in der Regel sind ein Hinweis darauf, dass das Cookie optional ist. Wenn dieses Cookie nicht vorhanden ist, kann die Regel immer noch erfolgreich angewendet werden, und die Cachespeicher-Kennung nimmt das Namen-Wert-Paar des Cookie nicht auf. Dadurch kann der Händler einen Preis, der nicht für eine Gruppe bestimmt ist, sowie einen Preis je Gruppe haben. Ein Beispiel für die Cachespeicher-Kennung wäre:

http://www.acmeStore.com/productDesc.jsp_productID=AT13394_groupID=*@#!
Bezug nehmend auf 11D ist eine Erweiterung des Szenarios mit der Käufergruppe gezeigt. Es fand eine Erweiterung um Unterstützung für mehrere Händler statt; zum Beispiel unterstützt ein Anwendungsdiensteanbieter (application service provider, ASP) mehrere Händler in demselben Web-Anwendungs-Server, indem er mehrere Sprachen verwendet. Das Produktbeschreibungs-Elternfragment enthält wieder ein Preis-Kindfragment. Das Elternfragment wird durch die Produktkennung (productID), die Händlerkennung (merchantID) und die Sprachkennung (languageID) logisch klassifiziert. Das Kindfragment wird durch die productID, die groupID, die languageID und die merchantID logisch klassifiziert. Die Seiten-URI hat einen Abfrageparameter "productID" und einen Abfrageparameter "merchantID". Die Anforderung hat die Cookies "userID", "groupID" und "languageID". Das Cookie "languageID" wird von der Web-Anwendung während der Anmeldung auf der Grundlage des Benutzerprofils erzeugt. Die languageID wird zu einem Cookie und nicht zu einem Abfrageparameter gemacht, da sie mit jeder Anforderung verwendet wird, und es wäre für den Entwickler der Web-Anwendung mühsam, sie in jede Verknüpfung zu stellen.
Die Regel für die einzige Cachespeicher-Kennung für das Elternfragment würde den URI-Pfad zusammen mit den Abfrageparametern "productID" und "merchantID" und dem Cookie "languageID" verwenden, so dass sie mit den richtigen Klassifizierungen zwischengespeichert werden kann. Die Regel für die Cachespeicher-Kennung für das Elternfragment würde lauten:

Fragment: cacheid="(productID merchantID, [languageID])"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad;
(B) dem Namen und dem Wert des Abfrageparameters "productID";
(C) dem Namen und dem Wert des Abfrageparameters "merchantID"; und
(D) dem Namen und dem Wert des Cookie "languageID", sofern es in der Anforderung vorhanden ist.

Ein Beispiel für die Cachespeicher-Kennung für das Elternfragment wäre:

http://www.acmeMall.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_languageID=eng
Die Regel für die einzige Cachespeicher-Kennung für das Kindfragment würde den URI-Pfad zusammen mit den Abfrageparametern "productID" und "merchantID" und dem Cookie "groupID" sowie optional dem Cookie "languageID" verwenden, so dass sie mit den richtigen Klassifizierungen zwischengespeichert werden kann. Die Regel für die Cachespeicher-Kennung würde lauten:

Fragment: cacheid="(productID merchantID,[groupID] [languageID])"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad;
(B) dem Namen und dem Wert des Abfrageparameters "productID";
(C) dem Namen und dem Wert des Abfrageparameters "merchantID";
(D) dem Namen und dem Wert des Cookie "groupID", sofern es in der Anforderung vorhanden ist; und
(E) dem Namen und dem Wert des Cookie "languageID", sofern es in der Anforderung vorhanden ist.

Ein Beispiel für die Cachespeicher-Kennung wäre:

http://www.acmeMall.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_groupID=*@#!_languageID=eng
Bezug nehmend auf 11E ist eine Erweiterung des Szenarios mit dem ASP und mehreren Sprachen gezeigt. Es fand eine Erweiterung um Unterstützung für mehrere Möglichkeiten zur Kennzeichnung von Produkten statt. Das Produktbeschreibungs-Elternfragment enthält ein Preis-Kindfragment. Das Elternfragment wird durch die productID (es gibt zwei Möglichkeiten, diese anzugeben), die languageID und die merchantID logisch klassifiziert. Das Kindfragment wird durch die productID, die groupID, die languageID und die merchantID logisch klassifiziert. Das Produkt wird entweder durch den Abfrageparameter "productID" oder durch die Abfrageparameter "partNumber" (Teilenummer) und "supplierNumber" (Lieferantennummer) gekennzeichnet. Die Anforderung hat die Cookies "userID", "groupID" und "languageID". Das Elternfragment würde zwei Regeln erfordern, die wie folgt angegeben werden:

Fragment: cacheid=
"(productID merchantID, [languageID])
(partNumber supplierNumber merchantID, [languageID])"
Die erste Regel wird ausprobiert. Wenn sie erfolgreich ist, legt sie die Cachespeicher-Kennung fest. Wenn sie fehlschlägt, wird die zweite Regel ausprobiert. Wenn die zweite Regel erfolgreich ist, legt sie die Cachespeicher-Kennung fest. Wenn sie fehlschlägt, wird das Fragment nicht zwischengespeichert. Die erste Regel bedeutet, dass die Cachespeicher-Kennung aus den folgenden miteinander verknüpften Teilen besteht:

Ein Beispiel für die Cachespeicher-Kennung für die erste Regel wäre:

http://www.acmeStore.com/productDesc.jsp_productID=AT13394_merchantID=MyStore_languageID=eng
Die zweite Regel bedeutet, dass die Cachespeicher-Kennung aus den folgenden miteinander verknüpften Teilen besteht:

(A) dem URI-Pfad;
(B) dem Namen und dem Wert des Abfrageparameters "partNumber";
(C) dem Namen und dem Wert des Abfrageparameters "supplierNumber";
(D) dem Namen und dem Wert des Abfrageparameters "merchantID"; und
(E) dem Namen und dem Wert des Cookie "languageID", sofern es in der Anforderung vorhanden ist.

Ein Beispiel für eine Cachespeicher-Kennung für die zweite Regel wäre:

http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_languageID=eng
Das Kindfragment erfordert zwei Regeln, die wie folgt angegeben werden:

Fragment: cacheid=
"(productID merchantID, [groupID] [languageID])
(partNumber supplierNumber merchantID, [groupID]
[languageID])"
Die erste Regel wird ausprobiert. Wenn sie erfolgreich ist, legt sie die Cachespeicher-Kennung fest. Wenn sie fehlschlägt, wird die zweite Regel ausprobiert. Wenn die zweite Regel erfolgreich ist, legt sie die Cachespeicher-Kennung fest. Wenn sie fehlschlägt, wird das Fragment nicht zwischengespeichert. Die erste Regel bedeutet, dass die Cachespeicher-Kennung aus den folgenden miteinander verknüpften Teilen besteht:

Ein Beispiel für eine Cachespeicher-Kennung für die erste Regel wäre:
http://www.acmeStore.com/productDesc.jsp_productID=AT13394_mer chantID=MyStore_groupID=*@#!_languageID=eng
Die zweite Regel bedeutet, dass die Cachespeicher-Kennung aus den folgenden miteinander verknüpften Teilen besteht:

(A) dem URI-Pfad;
(B) dem Namen und dem Wert des Abfrageparameters "partNumber";
(C) dem Namen und dem Wert des Abfrageparameters "supplierNumber";
(D) dem Namen und dem Wert des Abfrageparameters "merchantID";
(E) dem Namen und dem Wert des Cookie "groupID"; und
(F) dem Namen und dem Wert des Cookie "languageID".

Ein Beispiel für eine Cachespeicher-Kennung für die zweite Regel wäre:
http://www.acmeStore.com/productDesc.jsp_partNumber=22984Z_supplierNumber=339001_merchantID=MyStore_groupID=*@#!_language=eng
Bezug nehmend auf 11F ist eine Erweiterung des Szenarios mit der Produktbeschreibung gezeigt, wobei die Personalisierung zur Anwendung kommt. Ein Produktbeschreibungs-Elternfragment enthält ein Personalisierungs-Kindfragment. Das Elternfragment wird durch die productID logisch klassifiziert. Das Kindfragment wird durch die userID logisch klassifiziert. Die Seiten-URI hat einen Abfrageparameter "productID". Die Anforderung hat ein Cookie "userID".
Die Cachespeicher-Elternkennung enthält den Abfrageparameter "productID". Die Regel für die Cachespeicher-Kennung für das Elternfragment wäre einer der folgenden beiden Fälle:

Fragment: cacheid="URI"
Anders ausgedrückt, die Cachespeicher-Kennung ist die vollständige URI mit allen Abfrageparametern. Eine andere mögliche Regel wäre:

Fragment: cacheid="(productID)"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

Es sei angemerkt, dass die Anforderung für diese Seite zwar ein Cookie "userID" enthält, dieses aber nicht in der Cachespeicher-Kennung für eines der beiden Fragmente enthalten ist, da das Fragment produktspezifisch und nicht benutzerspezifisch ist. Wenn es enthalten wäre, könnte nur dieser Benutzer auf dieses Fragment zugreifen, was einen größeren Cachespeicher und einen höheren Arbeitsaufwand zur Folge hätte, um den Inhalt des Cachespeichers stets auf dem aktuellen Stand zu halten. Ein Beispiel für eine Cachespeicher-Kennung wäre:

http://www.acmeStore.com/productDesc.jsp_productID=AT13394
Die Cachespeicher-Kennung des Personalisierungs-Kindfragments enthält ein Cookie "userID". Die Regel für die Cachespeicher-Kennung des Kindfragments würde lauten:

Fragment: cacheid="(, userId)"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad; und
(B) dem Namen und dem Wert des Cookie "userID".

Ein Beispiel für eine Cachespeicher-Kennung wäre:

http://www.acmeStore.com/personalization.jsp_userID=@($*!%
In diesem Personalisierungsbeispiel sollten die Personalisierungsfragmente als private Daten gekennzeichnet werden, z. B., indem man den Kopfbereich "Cache-Control: private" verwendet.
Bezug nehmend auf 11G enthält ein Elternfragment in Form von einer Aktien-Beobachtungsliste auf einer einfachen Portalseite mehrere Kindfragmente in Form von Aktienkursen. Das Elternfragment enthält auch den Namen des Benutzers als eine einfache Personalisierung. Das Elternfragment wird durch die userID logisch klassifiziert, d. h., die Liste der Aktiensymbole ist benutzerspezifisch. Der Benutzername wird durch die userID logisch klassifiziert. Jedes Kindfragment wird durch sein Aktiensymbol logisch klassifiziert, d. h., der Wert einer Aktie ist nicht benutzerspezifisch. Die Seiten-URI enthält keine Abfrageparameter. Die Anforderung hat ein Cookie "userID".
Das Fragment der obersten Ebene enthält eine erforderliche benutzerspezifische Liste mit Aktienkursen. Die URI des Fragments der obersten Ebene enthält keine Abfrageparameter. Die Cachespeicher-Kennung des Fragments der obersten Ebene enthält ein verschlüsseltes Cookie mit der Bezeichnung "userID". Die Regel für die Cachespeicher-Kennung würde lauten:

Fragment: cacheid="(, userId)"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad; und
(B) dem Namen und dem Wert des Cookie "userID".

Ein Beispiel für eine Cachespeicher-Kennung wäre:

http://www.acmeInvest.com/stockList.jsp_userID=@($*!%
Für jedes der Aktienkurs-Fragmente enthält die Cachespeicher-Kennung den Parameter "symbol". Die Regel für die Cachespeicher-Kennung wäre die vollständige URI oder der URI-Pfad zuzüglich des Abfrageparameters "stockSymbol":

Fragment: cacheid="(stockSymbol)"
Anders ausgedrückt, die Cachespeicher-Kennung besteht aus den folgenden miteinander verknüpften Teilen:

(A) dem URI-Pfad; und
(B) dem Namen und dem Wert des Abfrageparameters "symbol".

Ein Beispiel für eine Cachespeicher-Kennung wäre:

http://www.acmeInvest.com/stockQuote.jsp_stockSymbol=IBM
Dieses Szenario kann so geändert werden, dass es das Merkmal FOREACH nutzt; die Aktienkurs-Fragmente würden sich nicht ändern, aber das Elternfragment kann deutlich optimiert werden. Es gibt nur ein statisches Fragment der obersten Ebene. Ein Cookie "stockSymbols" würde verwendet werden, dessen Wert eine durch Leerzeichen getrennte Liste mit Aktiensymbolen für den Benutzer ist. Es würde nur ein Elternfragment für alle Benutzer geben, das ziemlich statisch wäre und ein FRAGMENTLINK-Auszeichnungselement enthalten würde, dessen Attribut FOREACH einen Namen für das Cookie "stockSymbols" vergeben würde. Dies erzeugt dynamisch ein einfaches FRAGMENTLINK für jedes Aktiensymbol, dessen Attribut SRC gleich dem SRC des FRAGMENTLINK ist, welches das Attribut FOREACH enthält, wobei das Aktiensymbol als Abfrageparameter hinzugefügt wird. Da dieses Elternfragment bei allen Benutzern gleich ist, kann es mit den richtigen Klassifizierungen mit einer einzigen Cachespeicher-Regel, die seine URI als Cachespeicher-Kennung verwendet, welche keine Abfrageparameter hat, wie folgt zwischengespeichert werden:

Fragment: cacheid="URI"
Das Cookie "stockSymbols" enthält alle benutzerspezifischen Informationen für das Elternfragment und ist mit der Seitenanforderung unterwegs, so dass es die logische userID-Klassifizierung des Elternfragments erfüllt.
Ein Cookie "userName", dessen Wert der Name des Benutzers ist, würde in einem Auszeichnungselement FRAGMENTLINK für die einfache Personalisierung verwendet werden, deren Attribut SRC das Cookie "userName" kennzeichnet. Dieses Fragment wird nicht zwischengespeichert, da es leicht aus dem Cookie "userName" erzeugt werden kann. Das Cookie "userName" enthält alle benutzerspezifischen Informationen für dieses Fragment und ist mit der Seitenanforderung unterwegs, so dass es die logische userID-Klassifizierung des Elternfragments erfüllt.
Die Regel für die einzige Cachespeicher-Kennung für das Kindfragment verwendet dessen URI für die Cachespeicher-Kennung, so dass es mit den richtigen Klassifizierungen wie folgt zwischengespeichert werden kann:

Fragment: cacheid="URI"
In diesem Szenario mit der Aktien-Beobachtungsliste würden, wenn das Merkmal FOREACH nicht verwendet würde, die Fragmente der obersten Ebene in Form von der Aktien-Beobachtungsliste als private Fragmente gekennzeichnet werden, beispielsweise durch Verwendung von "Cache-Control: private". Wenn das Merkmal FOREACH verwendet wird, gibt es nur ein Fragment der obersten Ebene, das gemeinsam benutzt wird, so dass es nicht als privates Fragment gekennzeichnet wird.
Bezug nehmend auf 11H zeigt das Beispiel ein Szenario, das ähnlich einer personalisierten Portalseite ist, wie zum Beispiel myYahoo!. Ein Portalfragment der ersten Ebene enthält mehrere Themenfragmente der mittleren Ebene, wie zum Beispiel das Wetter, Aktien, Sport, von denen jedes mehrere Blattelement-Fragmente enthält. Das Elternfragment enthält auch den Namen des Benutzers. Das Portalfragment der obersten Ebene wird durch die userID logisch klassifiziert, d. h., die Liste der Themen ist benutzerspezifisch. Der Benutzername wird durch die userID logisch klassifiziert. Das Themenfragment der mittleren Ebene wird durch die Themen-Kennung (topicID) und die userID logisch klassifiziert, d. h., die Liste der Elemente bei dem Thema ist benutzerspezifisch. Das Blattelement-Fragment wird durch die Element-Kennung (itemID) logisch klassifiziert, d. h., der Wert eines Elements ist nicht benutzerspezifisch. Die Seiten-URI enthält keine Abfrageparameter. Die Seitenanforderung hat ein Cookie "userID". Durch die Verwendung des Merkmals FOREACH kann das Elternfragment in hohem Maße optimiert werden.
Wenn man das Merkmal FOREACH verwenden würde, würde ein Cookie "topics" (das während der Anmeldung auf der Grundlage des Benutzerprofils erzeugt worden wäre) verwendet werden, dessen Wert eine durch Leerzeichen getrennte Liste mit Themenkennungen (topicIDs) für diesen Benutzer wäre. Es würde nur ein Elternfragment für alle Benutzer geben, das ziemlich statisch wäre und ein FRAGMENTLINK-Auszeichnungselement enthalten würde, dessen Attribut FOREACH einen Namen für das Cookie "topics" vergeben würde. Dies erzeugt dynamisch ein einfaches FRAGMENTLINK für jede topicID, deren Attribut SRC gleich dem SRC des FRAGMENTLINK ist, welches das Attribut FOREACH enthält, wobei die topicID als Abfrageparameter angefügt wird. Da dieses Elternfragment bei allen Benutzern gleich ist, kann es mit den richtigen Klassifizierungen mit einer einzigen Cachespeicher-Regel, die seine URI als Cachespeicher-Kennung verwendet, welche keine Abfrageparameter hat, wie folgt zwischengespeichert werden:

Fragment: cacheid="URI"
Das Cookie "topics" enthält alle benutzerspezifischen Informationen für das Elternfragment und ist mit der Seitenanforderung unterwegs, so dass es die logische userID-Klassifizierung des Elternfragments erfüllt. Ein Cookie "userName", dessen Wert der Name des Benutzers ist, würde in einem Auszeichnungselement FRAGMENTLINK für die einfache Personalisierung verwendet werden, deren Attribut SRC das Cookie "userName" kennzeichnet. Dieses Fragment wird nicht zwischengespeichert, da es leicht aus dem Cookie "userName" erzeugt werden kann. Das Cookie "userName" enthält alle benutzerspezifischen Informationen für dieses Fragment und ist mit der Seitenanforderung unterwegs, so dass es die logische userID-Klassifizierung des Elternfragments erfüllt.
Für jedes Thema gibt es ein Themenfragment. Aufgrund des Merkmals FOREACH kann jedes der Themenfragmente in hohem Maße optimiert werden. Für jedes Thema würde ein Cookie (das während der Anmeldung auf der Grundlage des Benutzerprofils erzeugt worden wäre) verwendet werden, dessen Wert eine durch Leerzeichen getrennte Liste mit Elementkennungen (itemIDs) für diesen Benutzer und dieses Thema wäre. Für jedes Thema würde es nur ein Themenfragment für alle Benutzer geben, das ziemlich statisch wäre und ein FRAGMENTLINK-Auszeichnungselement enthalten würde, dessen Attribut FOREACH dem entsprechenden Cookie für dieses Thema einen Namen geben würde. Dies erzeugt dynamisch ein einfaches FRAGMENTLINK für jede itemID, deren Attribut SRC gleich dem SRC des FRAGMENTLINK ist, welches das Attribut FOREACH enthält, wobei die itemID als Abfrageparameter hinzugefügt wird (der Abfrageparameter "topicID" ist bereits vorhanden). Da jedes Themenfragment bei allen Benutzern gleich ist, kann es mit den richtigen Klassifizierungen mit einer einzigen Cachespeicher-Regel, die seine URI als Cachespeicher-Kennung verwendet, welche seine topicID als Abfrageparameter hat, zwischengespeichert werden. Das Cookie "topics" enthält alle benutzerspezifischen Informationen für das Themenfragment und ist mit der Seitenanforderung unterwegs, so dass es die logische userID-Klassifizierung des Themenfragments erfüllt.
Die URI für jedes Elementfragment enthält seine topicID und itemID als Abfrageparameter. Die Regel für die einzige Cachespeicher-Kennung für jedes Elementfragment verwendet dessen URI für die Cachespeicher-Kennung, so dass es mit den richtigen Klassifizierungen zwischengespeichert werden kann.
Beispiele für die Angabe von FRAGMENTLINK-Auszeichnungselementen
Nochmals Bezug nehmend auf das Beispiel der Seitenleiste in 11A würde anstelle der Seitenleiste ein einzelnes FRAGMENTLINK in der Seite platziert werden, und zwar an derselben Stelle, an der die Seitenleiste gewünscht ist, zum Beispiel:

{fragmentlink
src="http://www.acmeStore.com/sidebar.html"}
Nochmals Bezug nehmend auf das Beispiel der Käufergruppe in 11C würde sich an der Stelle, an der sich der Preis befinden würde, ein einzelnes FRAGMENTLINK befinden, zum Beispiel:

{fragmentlink
src="http://www.acmeStore.com/productPrice.jsp"}
Die URI, die für ein bestimmtes Preisfragment erstellt würde, würde folgendermaßen aussehen:

http://www.acmeStore.com/productPrice.jsp?productID=AT13394
Die Anforderung für das Fragment enthält alle Abfrageparameter des Elternfragments, d. h. "productID", und Cookies, d. h. "groupID", so dass sie während der Ausführung der productPrice.jsp im Anwendungs-Server zur Verfügung stehen.
Nochmals Bezug nehmend auf das Beispiel der Personalisierung in 11F würde das Fragment der obersten Ebene ein FRAGMENTLINK enthalten, das sich an der Stelle befinden würde, an der das personalisierte Fragment gewünscht ist, zum Beispiel:

{fragmentlink
src="http://www.acmeStore.com/personalization.jsp"}
Die URI, die für ein bestimmtes benutzerspezifisches Personalisierungsfragment erstellt würde, würde folgendermaßen aussehen:

http://www.acmeStore.com/personalization.jsp?productID=AT13394
Die Anforderung für das Fragment enthält alle Abfrageparameter des Elternfragments (d. h. "productID") und Cookies (d. h. "userID"). Während der Ausführung der personlization.jsp wird das Cookie "userID" verwendet, der Abfrageparameter "productID" wird jedoch ignoriert.
Nochmals Bezug nehmend auf das Beispiel der Aktien-Beobachtungsliste in 11G würde das Fragment der obersten Ebene eine veränderliche Anzahl von FRAGMENTLINK-Auszeichnungselementen enthalten, die von der Anzahl der Aktienkurse abhinge, die der Benutzer in Erfahrung hätte bringen wollen. Jedes FRAGMENTLINK-Auszeichnungselement würde sich an der Stelle befinden, an der sich die Aktienkurse befinden würden. Jedes FRAGMENTLINK würde folgendermaßen aussehen:

{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM"}
Die URI, die für ein bestimmtes Aktienkurs-Fragment erstellt würde, würde folgendermaßen aussehen:

http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM
Dieses Szenario kann so geändert werden, dass es das Merkmal FOREACH verwendet; die veränderliche Anzahl der FRAGMENTLINK-Auszeichnungselemente wird durch ein einziges FRAGMENTLINK-Auszeichnungselement ersetzt, wobei das Attribut FOREACH den Namen eines Cookie (Aktien) angibt, dessen Wert eine durch Leerzeichen getrennte Liste mit Aktiensymbol-Parametern ist:

{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp"
foreach="stocks"}
Wenn der Wert des Cookie mit dem Namen "stocks" symbol=IBM symbol=CSCO symbol=DELL lauten würde, würde dies der folgenden Gruppe von FRAGMENTLINK-Auszeichnungselementen entsprechen:

{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=IBM"}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=CSCO"}
{fragmentlink
src="http://www.acmeInvest.com/stockQuote.jsp?symbol=DELL"}
Nochmals Bezug nehmend auf das Beispiel mit dem ganzen Portal in 11H könnte das Merkmal FOREACH für ein einziges statisches Fragment der obersten Ebene verwendet werden, das von allen Benutzern gemeinsam benutzt würde. Das Cookie "userName" in dem Fragment der obersten Ebene würde unter Verwendung des folgenden FRAGMENTLINK-Auszeichnungselements aufgenommen werden, welches das Cookie "userName" kennzeichnet, welches den Namen des Benutzers enthält:

{fragmentlink src="cookie://userName"}
Das Fragment der obersten Ebene würde auch über ein FRAGMENTLINK-Auszeichnungselement verfügen, dessen Attribut FOREACH das Cookie "topics" kennzeichnet, welches die Themenliste dieses Benutzers enthält:

{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp"
foreach="topics"}
Dieses Cookie enthält eine Liste mit Kennungen von Themen (topicIDs). Bei einem Cookie "topics", das den folgenden Wert hat:

topic=stocks topic=weather topic=tv,

würde das vorstehende FRAGMENTLINK, welches das Attribut FOREACH enthält, die folgenden einfachen FRAGMENTLINKS erzeugen:

{fragment link
src="http://www.acmePortal.com/portalPage.jsp?topic=stocks"}
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=weather"}
{fragmentlink
src="http://www.acmePortal.com/portalPage.jsp?topic=tv"}
Jedes der dynamisch erzeugten SRC-Attribute findet ein Fragment auf, welches das angegebene Thema behandelt.
Durch die Ausführung der "portalPage.jsp" im Web-Anwendungs-Server dient portalPage.jsp als Zuteiler, der ein Fragment auf der Grundlage der Abfrageparameter aufruft. Kein Parameter liefert das Fragment der obersten Ebene zurück. Ein Abfrageparameter "topic=stocks" schickt das Themenfragment "Aktien" zurück. Wenn man das Themenfragment "Aktien" als Beispiel und nochmals das Merkmal FOREACH verwendet, enthält das Themenfragment "Aktien" ein FRAGMENTLINK-Auszeichnungselement, dessen Attribut FOREACH ein Cookie "stocks" kennzeichnet, das die Liste mit den Aktiensymbolen dieses Benutzers für dieses Thema enthält:

{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp"
foreach="stocks"}
Eine beispielhafte Verwendung hierfür wäre die Erzeugung von Zeilen einer Tabelle mit einer Zeile für jedes Aktiensymbol in dem Cookie "stocks". Bei einem Cookie "stocks", das den Wert
symbol=IBM symbol=DELL Symbol=CSCO

hat, würde das vorstehende FRAGMENTLINK, welches das Attribut FOREACH enthält, die folgenden FRAGMENTLINKS dynamisch erzeugen:

{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=IBM"}
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=DELL"}
{fragmentlink
src="http://www.stockQuotes.com/stockQuote.jsp?symbol=CSCO"}
Beispiele für die Weitergabe von Daten von einem Elternfragment an ein Kindfragment
Ein Fragment sollte so eigenständig wie möglich sein. Dafür gibt es zwei Gründe. Der erste Grund ist, dass eine gute Software-Technik vorgibt, dass Software-Module so unabhängig wie möglich sein sollten. Die Anzahl und die Komplexität der Verträge zwischen Modulen sollten auf ein Minimum herabgesetzt werden, so dass Änderungen in einem Modul lokal auf dieses Modul beschränkt sind und sich nicht auf andere Module erstrecken. Eine Anwendung könnte beispielsweise in einem Elternmodul befindliche Daten abrufen und diese Daten an ein Kindmodul weitergeben, das sie formatiert. Wenn dies geschieht, muss es einen Vertrag geben, der beschreibt, um was für Daten es sich handelt und wie sie weiterzugeben sind. Jede Änderung bei den Daten, die das Kindmodul benötigt, erfordert Änderungen an beiden Modulen. Wenn das Kindmodul stattdessen seine eigenen Daten abruft, beschränkt sich die Änderung lediglich auf das Kindmodul. Wenn die Notwendigkeit besteht, eines der Module unabhängig von der Art und Weise zu machen, in der seine Daten abgerufen werden, oder wenn der Code, der seine Daten abruft, in mehreren Modulen gleich ist, können eine getrennte Daten-Bean und ein entsprechender Vertrag verwendet werden, um sowohl die eine als auch die andere Anforderung zu erfüllen. Fügt man jedoch noch einen weiteren Vertrag zwischen dem Elternmodul und dem Kindmodul hinzu, so stellt dies lediglich zusätzliche Komplexität dar, ohne damit etwas zu erreichen.
Der zweite Grund dafür, dass ein Fragment so eigenständig wie möglich sein sollte, ist, dass der Code, der ein Fragment erzeugt, ebenfalls eigenständig sein sollte, um die Zwischenspeicherung leistungsfähig zu machen. In dem vorstehenden Beispiel nimmt das Kindmodul selbst nur eine Formatierung vor, wenn das Elternmodul alle Daten für das Kindmodul abruft und sie an das Kindmodul weitergibt. Bei dieser Abhängigkeit zwischen Modulen müssen sowohl das Elternmodul als auch das Kindmodul ungültig gemacht und neu erzeugt werden, wenn die von dem Kindmodul benötigten Daten veralten. Die Abhängigkeit macht eine Zwischenspeicherung der getrennten Fragmente weitaus weniger leistungsfähig. Ein Fragment, das von mehreren Elternmodulen gemeinsam benutzt wird, verschärft beide der vorstehenden Probleme.
Das JSP-Programmiermodell ermöglicht die Weitergabe von Daten zwischen JSPs über Anforderungsattribute oder einen Sitzungszustand. Bei verschachtelten Fragmenten funktioniert der Mechanismus in Form des Anforderungsattributs nicht, da die Eltern-JSP und die Kind-JSP in verschiedenen an den Anwendungs-Server gerichteten Anforderungen abgerufen werden können. Der Mechanismus in Form des Sitzungszustands funktioniert gegebenenfalls auch nicht, wenn die Eltern-JSP und die Kind-JSP in verschiedenen Sitzungen ausgeführt werden können. Stattdessen sollten alle Daten, die weitergegeben werden sollen, URI-Abfrageparameter oder Cookies verwenden. Selbst eine komplexe Datenstruktur, die unter Verwendung von Anforderungsattributen von der Eltern-JSP an die Kind-JSP weitergegeben würde, könnte dennoch weitergereicht werden, wenn man sie parallel-seriell umsetzt und als Abfrageparameter in die URI im SRC-Attribut des FRAGMENTLINK-Auszeichnungselements aufnimmt.
Selbst wenn Fragmente ihre eigenen Daten abrufen, besteht immer noch die Notwendigkeit, einige Steuerdaten zwischen ihnen zu übertragen. Nochmals Bezug nehmend auf die vorstehenden Beispiele werden in dem Szenario mit der Seitenleiste keine Daten von den Fragmenten der obersten Ebene an die Seitenleiste übertragen. In dem Szenario mit der Käufergruppe muss dem Produktbeschreibungs-Fragment der obersten Ebene die Produktkennung bekannt sein, und dem Kindfragment in Form des gruppenproduktspezifischen Preises muss sowohl die Produktkennung als auch die Kennung der Käufergruppe bekannt sein. Die Produktkennung wird von der externen Anforderung geliefert. Die Kennung der Käufergruppe wird von der Anwendung mittels der Benutzerkennung erzeugt; beide Kennungen werden zum Zeitpunkt der Anmeldung erzeugt. Sowohl die Produktkennung als auch die Kennung der Käufergruppe sollten über das Produktbeschreibungs-Fragment an das Preisfragment weitergegeben werden. Alle URI-Abfrageparameter und Cookies werden automatisch an das Kindfragment weitergereicht.
In dem Personalisierungs-Szenario muss dem Produktbeschreibungs-Fragment der obersten Ebene die Produktkennung bekannt sein, und dem Personalisierungs-Kindfragment muss die Benutzerkennung bekannt sein. Diese beiden Parameter werden von der externen Anforderung geliefert, so dass die Benutzerkennung über das Produktbeschreibungs-Fragment an das Personalisierungsfragment weitergegeben werden sollte. Dies geschieht, indem das Cookie mit der Bezeichnung "userID" an das Kindfragment weitergereicht wird.
In dem Szenario mit der Aktien-Beobachtungsliste muss dem Fragment der obersten Ebene in Form von der Aktien-Beobachtungsliste das Cookie mit der Benutzerkennung bekannt sein, und jedem der Kindfragmente in Form von den Aktienkursen muss das Aktiensymbol bekannt sein. Die Aktiensymbole und die FRAGMENTLINK-Auszeichnungselemente, die sie enthalten, werden als Teil des Fragments der obersten Ebene in Form von der Aktien-Beobachtungsliste erzeugt. Das Aktiensymbol sollte dem Aktienkurs-Fragment übergeben werden. Dies geschieht, indem man das Aktiensymbol als ein Abfrageparameter der URI in das SRC-Attribut des FRAGMENTLINK-Auszeichnungselements stellt.
Beispiele für FRAGMENTLINK-Auszeichnungselemente und FRAGMENT-Kopfbereiche
Nun Bezug nehmend auf die Tabellen 1A bis 1C ist eine Reihe von HTML- und HTTP-Anweisungen für das vorstehend erörterte Beispiel der Seitenleiste gezeigt. Beide Fragmente in diesem Szenario sind statisch. Das Elternfragment der obersten Ebene wäre eine JSP, da es ein weiteres Fragment enthält, das "jsp:include" verwendet, und da die Cachespeicher- Steuerinformationen dem Elternfragment zugeordnet werden müssen. Das Seitenleisten-Kindfragment ist ebenfalls eine JSP, da diesem Fragment Steuerinformationen für die Zwischenspeicherung zuzuordnen sind, es enthält jedoch keine JSP-Auszeichnungselemente.
Tabelle 1A zeigt eine JSP, die HTML-Anweisungen für das Fragment der obersten Ebene enthält, welches das Seitenleisten-Fragment enthält.
Tabelle 1B zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Fragment der obersten Ebene erzeugt werden würde.
Tabelle 1C zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Seitenleisten-Fragment erzeugt werden würde.
Nun Bezug nehmend auf die Tabellen 2A bis 2D ist eine Reihe von HTML- und HTTP-Anweisungen für das vorstehend erörterte Beispiel der Käufergruppe gezeigt. Beide Fragmente in diesem Szenario sind dynamisch. Eine JSP wird für das Fragment der obersten Ebene verwendet, welches das produktgruppenspezifische Preisfragment enthält. Das Kindfragment ist ebenfalls eine JSP, da es Geschäftsanwendungslogik zum Abrufen des entsprechenden Preises enthält.
Tabelle 2A zeigt eine JSP, die HTML-Anweisungen für das Fragment der obersten Ebene in Form von der Produktbeschreibung enthält, welches das Kindfragment enthält.
Tabelle 2B zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Fragment in Form von der Produktbeschreibung erzeugt werden würde.
Tabelle 2C zeigt eine JSP, die HTML-Anweisungen für das Kindfragment in Form von dem produktgruppenspezifischen Preis enthält.
Tabelle 2D zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Fragment in Form von dem produktgruppenspezifischen Preis erzeugt werden würde.
Nun Bezug nehmend auf die Tabellen 3A bis 3D ist eine Reihe von HTML- und HTTP-Anweisungen für das vorstehend erörterte Beispiel der Personalisierung gezeigt. Beide Fragmente in diesem Szenario sind dynamisch. Eine JSP, die das Fragment der obersten Ebene in Form von der Produktbeschreibung erzeugt, enthält ein einzelnes benutzerspezifisches Personalisierungsfragment. Das Kindfragment ist ebenfalls eine JSP, da es Geschäftsanwendungslogik zum Abrufen der entsprechenden Personalisierungsdaten für den Benutzer enthält.
Tabelle 3A zeigt eine JSP, die HTML-Anweisungen für das Fragment der obersten Ebene in Form von der Produktbeschreibung enthält, welches das Kindfragment enthält.
Tabelle 3B zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Fragment in Form von der Produktbeschreibung erzeugt werden würde.
Tabelle 3C zeigt eine JSP, die HTML-Anweisungen für das benutzerspezifische Kindfragment enthält.
Tabelle 3D zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Kindfragment erzeugt werden würde.
Nun Bezug nehmend auf die Tabellen 4A bis 4F ist eine Reihe von HTML- und HTTP-Anweisungen für das vorstehend erörterte Beispiel der Aktien-Beobachtungsliste gezeigt. Beide Fragmente in diesem Szenario sind dynamisch.
Tabelle 4A zeigt eine JSP, die das Fragment der obersten Ebene in Form von der Aktien-Beobachtungsliste erzeugt, das mehrere Fragmente in Form von Aktienkursen enthält. Das Auszeichnungselement "jspext:cookie" zeigt den Namen des Benutzers an, der im Cookie mit der Bezeichnung "userName" angegeben ist. Dieses Beispiel erzeugt dynamisch eine veränderliche Anzahl von Aufrufen der Methode "RequestDispatcher.include", von denen jeder ein FRAGMENTLINK-Auszeichnungselement in der Ausgabe erzeugt.
Tabelle 4B zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Fragment in Form von der Aktien-Beobachtungsliste erzeugt werden würde.
Tabelle 4C zeigt eine JSP, die das Fragment der obersten Ebene in Form von der Aktien-Beobachtungsliste erzeugt, welches ein Attribut FOREACH enthält.
Tabelle 4D zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für das Fragment der obersten Ebene in Form von einer Aktien-Beobachtungsliste, welches ein Attribut FOREACH enthält, erzeugt werden würde.
Tabelle 4E zeigt eine JSP, die den einzelnen Aktienkurs erzeugt.
Tabelle 4F zeigt die HTTP-Ausgabe, die von einem Web-Anwendungs-Server für einen Symbol-Abfrageparameter "IBM" erzeugt werden würde.
Schlussfolgerung
Die Vorteile der bevorzugten Ausführungsform der vorliegenden Erfindung dürften in Anbetracht der vorstehenden ausführlichen Beschreibung der bevorzugten Ausführungsform der Erfindung offensichtlich sein. Ein Verfahren zur Zwischenspeicherung von Fragmenten kann in einer Cachespeicher-Verwaltungseinheit ausgeführt werden, die überall in einem Netzwerk in Datenverarbeitungseinheiten eingesetzt werden kann, so dass die Cachespeicher-Verwaltungseinheiten einen Mechanismus zur verteilten Zwischenspeicherung von Fragmenten bereitstellen.
Ein FRAGMENT-Kopfbereich wird zur Verwendung in einem Netzwerkprotokoll wie beispielsweise HTTP festgelegt; der Kopfbereich ordnet einem Fragment Metadaten für verschiedene Zwecke zu, die sich auf die Verarbeitung und die Zwischenspeicherung eines Fragments beziehen. Der Kopfbereich dient beispielsweise zur Feststellung, ob der Client, der Server oder aber ein dazwischengeschalteter Cachespeicher über Funktionen zur Zusammensetzung von Seiten verfügt. Der Kopfbereich legt auch Regeln für die Cachespeicher-Kennung fest, um eine Cachespeicher-Kennung für ein Fragment zu bilden; diese Regeln können auf einer URI für das Fragment oder auf dem URI-Pfad sowie auf einer Kombination aus den Abfrageparametern von der URI und Cookies, die der Anforderung beigefügt sind, beruhen. Darüber hinaus kann der Kopfbereich die Abhängigkeitsbeziehungen von Fragmenten zur Unterstützung von Operationen zum Ungültigmachen, die von einem Hostrechner eingeleitet werden, angeben.
Ein Auszeichnungselement FRAGMENTLINK wird verwendet, um die Stelle in einer Seite für ein aufzunehmendes Fragment anzugeben, das während der Zusammensetzung der Seite oder während der Darstellung der Seite eingefügt werden soll. Ein FRAGMENTLINK-Auszeichnungselement enthält per definitionem ausreichend Informationen, um das verknüpfte Fragment entweder in einem Cachespeicher zu suchen oder es von einem Server abzurufen. Regeln für die Cachespeicher-Kennung werden sowohl verwendet, wenn ein Fragment im Cachespeicher gespeichert wird, als auch, wenn eine Quellenkennung von einer Anforderung, das Fragment im Cachespeicher zu suchen, verarbeitet wird. Um das Fragment im Cachespeicher zu suchen, wird mittels der Regeln für die Cachespeicher-Kennung, die zum URI-Pfad des Fragments gehören, die Cachespeicher-Kennung festgelegt. Die Regeln erlauben ein hohes Maß an Flexibilität bei der Bildung einer Cachespeicher-Kennung für ein Fragment, ohne dass ein Rechnerprogramm eingesetzt werden muss, das eine standardmäßige Ausführung zur Bildung einer Cachespeicher-Kennung erzwingt. Es können mehrere Regeln für die Cachespeicher-Kennung zur Anwendung kommen. Die Regeln für die Cachespeicher-Kennung lassen als Cachespeicher-Kennung eine vollständige URI für ein Fragment oder die URI und eine Kombination aus Abfrageparametern oder Cookies zu. Bei diesem Schema kann dasselbe FRAGMENTLINK verschiedene Fragmente in Abhängigkeit von den Abfrageparametern und den Cookies des Elternfragments auffinden; zum Beispiel könnte ein Cookie mit der Benutzerkennung in der Anforderung für eine Seite einer Produktbeschreibung verwendet werden, um die Cachespeicher-Kennung für ein Personalisierungsfragment zu bilden.
Es sollte nicht unerwähnt bleiben, dass die bevorzugte Ausführungsform der vorliegenden Erfindung zwar im Zusammenhang mit einem uneingeschränkt funktionierenden Datenverarbeitungssystem beschrieben wurde, der Fachmann aber versteht, dass ein Teil der Prozesse in Verbindung mit einer bevorzugten Ausführungsform der vorliegenden Erfindung in Form von Befehlen auf einem rechnerlesbaren Datenträger und in einer Vielzahl von anderen Formen vertrieben werden kann, und zwar ungeachtet der jeweiligen Art der Signal tragenden Medien, die tatsächlich zum Vertrieb verwendet werden. Zu Beispielen für rechnerlesbare Datenträger gehören Datenträger wie zum Beispiel ein EPROM, ein ROM, ein Band, Papier, eine Diskette, ein Festplattenlaufwerk, ein RAM und CD-ROMS sowie Übertragungsmedien wie zum Beispiel digitale und analoge Datenübertragungsverbindungen.

Claims

Verfahren zum Verarbeiten von Objekten in einem Datenverarbeitungssystem in einem Netzwerk, wobei das Verfahren die folgenden Schritte umfasst: Empfangen (6002) einer ersten Nachricht an einer Datenverarbeitungseinheit; und Feststellen (6004), dass ein Nachrichtenkopf in der ersten Nachricht angibt, dass die erste Nachricht zu einem Fragment gehört; und dadurch gekennzeichnet ist, dass das Verfahren des Weiteren den Schritt des Feststellens (6010), ob das Fragment zwischengespeichert werden kann, anhand eines Nachrichtenkopfs in der ersten Nachricht umfasst.
Verfahren nach Anspruch 2, das des Weiteren die folgenden Schritte umfasst: Speichern (6014) eines Fragments der ersten Nachricht in einem Cachespeicher; Empfangen einer zweiten Nachricht an der Datenverarbeitungseinheit, wobei die zweite Nachricht eine Anforderung für das Fragment umfasst; Durchsuchen des Cachespeichers als Reaktion auf den Empfang der zweiten Nachricht; Abrufen des Fragments aus dem Cachespeicher als Reaktion auf das Durchsuchen des Cachespeichers; und Senden des Fragments in einer dritten Nachricht an einen Ersteller der zweiten Nachricht, ohne die zweite Nachricht an ihre Zieladresse zu senden.
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: Feststellen, ob das Fragment ein Fragment der obersten Ebene ist, das eine Verknüpfung zu einem Fragment der nächsten Ebene enthält; Abrufen des Fragments der nächsten Ebene als Reaktion auf die Feststellung, dass das Fragment ein Fragment der obersten Ebene ist, welches eine Verknüpfung zu einem Fragment der nächsten ebene enthält; und Zusammenfassen des Fragments der obersten Ebene und des Fragments der nächsten Ebene zu einem zusammengesetzten Fragment.
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: Abrufen einer Gruppe von Abhängigkeitskennungen aus der ersten Nachricht, wobei eine Abhängigkeitskennung von einem Server erzeugt wird, von dem das Fragment stammt; Speichern eines Fragments der ersten Nachricht in einem Cachespeicher; und Speichern der Gruppe der Abhängigkeitskennungen in Verbindung mit einer Quellenkennung für das Fragment.
Verfahren nach Anspruch 4, das des Weiteren die folgenden Schritte umfasst: Empfangen einer Anforderungsnachricht für eine Ungültigmachung; Abrufen einer Abhängigkeitskennung von der Anforderungsnachricht für die Ungültigmachung; Feststellen einer Gruppe von Fragmenten, die zu der Abhängigkeitskennung gehören; und Löschen der Gruppe von Fragmenten aus dem Cachespeicher als Reaktion auf die Feststellung der Gruppe von Fragmenten, die zu der Abhängigkeitskennung gehören.
Verfahren nach Anspruch 1, das des Weiteren die folgenden Schritte umfasst: Abrufen einer Gruppe von Regeln für die Zwischenspeicherung von Fragmenten aus der ersten Nachricht, wobei eine Regel für die Zwischenspeicherung von Fragmenten eine Weise zur Erzeugung einer Cachespeicher-Kennung für das Fragment festlegt; Erzeugen einer Cachespeicher-Kennung für das Fragment gemäß einer Regel für die Zwischenspeicherung von Fragmenten; und Durchführen einer Speicheroperation unter Verwendung der erzeugten Cachespeicher-Kennung für das Fragment.
Verfahren nach Anspruch 1, wobei die erste Nachricht eine Quellenkennung für das Fragment umfasst, wobei das Verfahren die folgenden weiteren Schritte umfasst: Erzeugen einer Antwortnachricht, die das Fragment umfasst; und Einfügen eines Nachrichtenkopfes in die Antwortnachricht, der angibt, dass die erste Nachricht zu einem Fragment gehört.
Verfahren nach Anspruch 7, das des Weiteren den folgenden Schritt umfasst: Einfügen eines Nachrichtenkopfes in die Antwortnachricht, der angibt, dass das Fragment zwischengespeichert werden kann.
Datenverarbeitungseinheit zum Verarbeiten von Objekten in einem Datenverarbeitungssystem in einem Netzwerk, wobei die Einheit Folgendes umfasst: ein Mittel (6002), um eine erste Nachricht zu empfangen; und ein Mittel (6004), um festzustellen, dass ein Nachrichtenkopf in der ersten Nachricht angibt, dass die erste Nachricht zu einem Fragment gehört; und dadurch gekennzeichnet ist, dass die Einheit des Weiteren über ein Mittel (6010) verfügt, um anhand eines Nachrichtenkopfs in der ersten Nachricht festzustellen, ob das Fragment zwischengespeichert werden kann.
Datenverarbeitungseinheit nach Anspruch 9, die des Weiteren Folgendes umfasst: ein Mittel, um ein Fragment der ersten Nachricht in einem Cachespeicher zu speichern; ein Mittel, um eine zweite Nachricht zu empfangen, wobei die zweite Nachricht eine Anforderung für das Fragment umfasst; ein Mittel, um den Cachespeicher als Reaktion auf den Empfang der zweiten Nachricht zu durchsuchen; ein Mittel, um das Fragment als Reaktion auf das Durchsuchen des Cachespeichers aus dem Cachespeicher abzurufen; und ein Mittel, um das Fragment in einer dritten Nachricht an einen Ersteller der zweiten Nachricht zu senden, ohne die zweite Nachricht an ihre Zieladresse zu senden.
Datenverarbeitungseinheit nach Anspruch 9, die des Weiteren Folgendes umfasst: ein Mittel, um festzustellen, ob das Fragment ein Fragment der obersten Ebene ist, das eine Verknüpfung zu einem Fragment der nächsten Ebene enthält; ein Mittel, um das Fragment der nächsten Ebene als Reaktion auf die Feststellung, dass das Fragment ein Fragment der obersten Ebene ist, welches eine Verknüpfung zu einem Fragment der nächsten Ebene enthält, abzurufen; und ein Mittel, um das Fragment der obersten Ebene und das Fragment der nächsten Ebene zu einem zusammengesetzten Fragment zusammenzufassen.
Datenverarbeitungseinheit nach Anspruch 9, die des Weiteren Folgendes umfasst: Ein Mittel zum Abrufen einer Gruppe von Abhängigkeitskennungen aus der ersten Nachricht, wobei eine Abhängigkeitskennung von einem Server erzeugt wird, von dem das Fragment stammt; ein Mittel, um ein Fragment der ersten Nachricht in einem Cachespeicher zu speichern; und ein Mittel, um die Gruppe der Abhängigkeitskennungen in Verbindung mit einer Quellenkennung für das Fragment zu speichern.
Datenverarbeitungseinheit nach Anspruch 12, die des Weiteren Folgendes umfasst: ein Mittel, um eine Anforderungsnachricht für eine Ungültigmachung zu empfangen; ein Mittel, um eine Abhängigkeitskennung aus der Anforderungsnachricht für die Ungültigmachung abzurufen; ein Mittel, um eine Gruppe von Fragmenten festzustellen, die zu der Abhängigkeitskennung gehören; und ein Mittel, um als Reaktion auf die Feststellung der Gruppe von Fragmenten, die zu der Abhängigkeitskennung gehören, die Gruppe von Fragmenten aus dem Cachespeicher zu löschen.
Datenverarbeitungseinheit nach Anspruch 9, die des Weiteren Folgendes umfasst: ein Mittel, um eine Gruppe von Regeln für die Zwischenspeicherung von Fragmenten aus der ersten Nachricht abzurufen, wobei eine Regel für die Zwischenspeicherung von Fragmenten eine Weise zur Erzeugung einer Cachespeicher-Kennung für das Fragment festlegt; ein Mittel, um eine Cachespeicher-Kennung für das Fragment gemäß einer Regel für die Zwischenspeicherung von Fragmenten zu erzeugen; und ein Mittel, um die Speicheroperation unter Verwendung der erzeugten Cachespeicher-Kennung für das Fragment durchzuführen.
Datenverarbeitungseinheit nach Anspruch 9, wobei die Anforderungsnachricht eine Quellenkennung für ein Fragment umfasst, wobei die Datenverarbeitungseinheit des Weiteren Folgendes umfasst: ein Mittel, um eine Antwortnachricht zu erzeugen, die das Fragment umfasst; und ein Mittel, um einen Nachrichtenkopf in die Antwortnachricht einzufügen, der angibt, dass die erste Nachricht zu einem Fragment gehört.
Datenverarbeitungseinheit nach Anspruch 15, die des Weiteren Folgendes umfasst: ein Mittel, um einen Nachrichtenkopf in die Antwortnachricht einzufügen, der angibt, dass das Fragment zwischengespeichert werden kann.
Verfahren zum Verarbeiten von Objekten in einem Datenverarbeitungssystem in einem Netzwerk, wobei das Verfahren Folgendes umfasst: Empfangen (924) einer Anforderungsnachricht an einem Server, wobei die Anforderungsnachricht eine Quellenkennung für ein Fragment umfasst; Erzeugen einer Antwortnachricht, die das Fragment umfasst; Einfügen eines Nachrichtenkopfes in die Antwortnachricht, der angibt, dass die erste Nachricht zu einem Fragment gehört; und dadurch gekennzeichnet ist, dass das Verfahren des Weiteren den Schritt des Einfügens eines Nachrichtenkopfs in die Antwortnachricht umfasst, der angibt, ob das Fragment zwischengespeichert werden kann.
Datenverarbeitungseinheit zum Verarbeiten von Objekten in einem Datenverarbeitungssystem in einem Netzwerk, wobei die Einheit Folgendes umfasst: ein Mittel, um eine Anforderungsnachricht an einem Server zu empfangen (924), wobei die Anforderungsnachricht eine Quellenkennung für ein Fragment umfasst; ein Mittel, um eine Antwortnachricht zu erzeugen, die das Fragment umfasst; ein Mittel, um einen Nachrichtenkopf in die Antwortnachricht einzufügen, der angibt, dass die erste Nachricht zu einem Fragment gehört; und dadurch gekennzeichnet ist, dass die Einheit des Weiteren ein Mittel umfasst, um einen Nachrichtenkopf in die Antwortnachricht einzufügen, der angibt, ob das Fragment zwischengespeichert werden kann.
Rechnerlesbarer Datenträger, der ein Rechnerprogramm zur Verwendung in einem Datenverarbeitungssystem in einem Netzwerk umfasst, um Objekte zu verarbeiten, wobei das Rechnerprogramm Befehle zur Durchführung des Verfahrens nach einem der Ansprüche 1 bis 8 oder nach dem Anspruch 17 umfasst.