DE10051024A1 - Methode zum Einrichten optimaler intermediärer Cachingpunkte durch Gruppierung von Programmelementen in einem Softwaresystem - Google Patents

Abstract

Ein Satz von Programmelementen (z. B. Umcodierer) wird zu einer administrativen Einheit zusammengefasst. Anstatt die einzelnen Ausgänge eines jeden Programmelements im Cache zu speichern, wird vorzugsweise nur der Gesamtausgang des Satzes von Programmelementen als ganzes im Cache gespeichert. Die Technik der Erfindung ermöglicht die wirksame Wiederverwendung eines Zwischeninhalts. In einem Beispiel einer Client-Server-basierten Implementierung, die einen in einem Server befindlichen Umcodierungsdienst betrifft, können die im Cache gespeicherten Informationen von mehreren Serverinstanzen gemeinsam genutzt werden, um eine redundante Verarbeitung zu vermeiden. Mit der vorliegenden Erfindung kann ein Caching-Mechanismus in einem komplexen Softwaresystem benutzerkonfigurierbar erweitert werden, indem optimale intermediäre Cachingpunkte eingerichtet werden, die durch in langen Berechnungen definierte Programmgruppen definiert werden.

Description

HINTERGRUND DER ERFINDUNG Technisches Gebiet

Die vorliegende Erfindung betrifft allgemein die Verwaltung von Daten in einem komplexen Computersystem und im Besonderen ein Verfahren zum Wiederverwenden von Softwareelementen in einem solchen System, zur Vereinfachung eines effizienten intermediären Caching von Daten.

Stand der Technik

Intermediaries sind Recheneinheiten, die an einer beliebigen Stelle in einem Datenstrom, beispielsweise einem HTTP-Strom, plaziert werden können und die so programmiert werden, dass sie die Daten auf ihrem Weg durch den Datenstrom kundenspezifisch anpassen, personalisieren oder auf andere Weise destillieren oder verbessern. Ein Caching Web Proxy ist ein einfaches Beispiel für ein HTTP-Intermediary. Eine Intermediary-basierte Programmierung ist besonders nützlich, um einem System weitere Funktionen hinzuzufügen, wenn der Datenerzeuger (z. B. ein Server oder eine Datenbank) oder der Datenverbraucher (z. B. ein Browser) nicht verändert werden können.

Web Intermediaries (oder WBI, ausgesprochen "webby"), eine bekannte Intermediary-Architektur und -Framework, dient der Erzeugung von intermediären Applikationen im Web. Grundlegend ist WBI ein programmierbarer Web Proxy und Web Server, der in Verbindung mit einem Web Development Kit mit Java APIs für den Aufbau von intermediären Web-Applikationen innerhalb des WBI-Frameworks benutzt werden kann. Als Beispiele für intermediäre Applikationen wären zu nennen: Umcodierung eines Inhalts zwischen verschiedenen Formaten, Personalisierung, Passwort- und Privatsphärenverwaltung, Interaktivität und Inhaltsfilterung. WBI ist nur ein Beispiel für eine Architektur zur Verwaltung von Web Intermediaries. Andere konzeptionelle Techniken umfassen beispielsweise die Verkettung von Java-basierten Servlets.

Umcodierung ist der Prozess, in dem ein Datenobjekt einer bestimmten Darstellung in eine andere Darstellung umgewandelt wird. Typische Beispiele sind die Konvertierung innerhalb eines Medientyps (z. B. wird ein Bild, das nach einem bestimmten Standard codiert wurde, in ein Bild umcodiert, das nach einem zweiten Standard codiert wurde) sowie die Konvertierung zwischen verschiedenen Medientypen (z. B. Sprache in Text). Ein Umcodierer ist ein Funktionsmodul, typischerweise in Form eines Computercodes, das einen Datenstrom als Eingang annimmt und einen Datenstrom als Ausgang erzeugt. Der erzeugte Ausgangsstrom basiert auf dem Eingangsstrom und der gewünschten Funktion des Umcodierers. Ein Satz von "n" Umcodierern kann verkettet oder in anderer Form zu einer Gruppe zusammengefasst sein, um ein Umcodierer- Proxy-Framework zu bilden. In einem gegebenen Umcodierer könnte die Umcodierungsfunktion eine Operation aus einer beliebigen Anzahl von Operationen sein, wie z. B.: ein Anforderungsmodifizierer, ein Inhaltseditor, ein Inhaltsgenerator oder ähnliches. Der Ausgangsstrom eines gegebenen Umcodierers kann auch auf einer ursprünglichen Anforderung oder einer modifizierten Anforderung, einer histographischen Information auf bereits vorhandenen Umcodierungspfaden, und/oder auf externen Präferenzen (z. B. Netzanschlussgeschwindigkeit, Fähigkeiten des Kundengeräts, User-Präferenzen und ähnliches) basieren, die in einer separaten Datenbank eingerichtet wurden.

Das WBI-Backbone bietet eine gut definierte Schnittstelle, bekannt als Teilschicht, die Anforderungen annimmt und Antworten erzeugt. In einem Server, der das WBI-Framework unterstützt, können viele Teilschichten vorhanden sein, die jeweils Anforderungen von einer anderen Quelle annehmen (z. B. von einem Proxy, der einen Port abhört, einem seriellen Port, einem Servlet und ähnliches) und ein bestimmtes Protokoll abwickeln (z. B. HTTP, FTP, POP3 und ähnliche). Eine Teilschicht gibt Anweisungen an das WBI-Backbone, wie eine Anforderung verarbeitet werden soll, indem sie einen Regelsatz bereitstellt, der beschreibt, wie eine Antwort erzeugt werden soll. Das Backbone dient als Regel-Maschine (RM), welche die vorhandenen Regeln zur Abbildung einer Anforderung auf einen Satz von Plugins verwendet, die dann die eigentliche Umcodierung des Inhalts durchführen. Bei der Erzeugung einer Antwort auf eine gegebene Anforderung kann auch eine Reihe von Zwischenschritten (Plugins) ausgeführt werden. Es ist wünschenswert, den Ausgang dieser Zwischenschritte wieder zu verwenden, weil viele Anforderungen (von verschiedenen Clients) wahrscheinlich gemeinsame Schritte enthalten und weil der Overhead für die erneute Erzeugung eines ähnlichen Ausgangs durch einen Caching-Mechanismus vermieden werden kann. Es kann auch vorkommen, dass ein gegebener Client eine Ressource anfordert, die bereits vor kurzem angefordert wurde. Nehmen wir einmal an, dass ein User sich in sein Konto einloggt, um den Status eines Online-Auftrags zu prüfen. Wenn sich der Auftragsstatus nicht verändert hat, dürfte es nicht notwendig sein, die Statusseite, die an den User zurückgemeldet werden soll, nochmals zu erzeugen. Die Seite müßte im Cache gespeichert sein, wobei die Lebensdauer der Seite von den Cache-Ablaufmodalitäten gesteuert wird.

Eines der Hauptprobleme beim Caching von Zwischendaten ist jedoch die geeignete Granularität des Caching. Wenn die Anzahl der intermediären Punkte, an denen während der Ausführung die Daten im Cache gespeichert werden, nicht mit der Zeit in Einklang gebracht wird, die für das Erzeugen und Sichern der Zwischendaten benötigt wird, ist das intermediäre Caching für die System-Performanz gegenproduktiv.

Die vorliegende Erfindung spricht das Problem an, wie ein intermediäres Caching in einem komplexen Softwaresystem, wie es beispielsweise oben beschrieben wurde, wirksam durchgeführt werden kann.

KURZE ZUSAMMENFASSUNG DER ERFINDUNG

Entsprechend der vorliegenden Erfindung wird ein Satz von Programmelementen (z. B. Umcodierer) in einer Gruppe zusammengefasst und für Caching-Zwecke als eine Einheit verwaltet. Anstatt die einzelnen Ausgänge eines jeden Programmelements im Cache zu speichern, wird vorzugsweise nur der Gesamtausgang der Programmelement-Gruppe als Ganzes im Cache gespeichert. Die Technik der Erfindung ermöglicht die wirksame Wiederverwendung der Programmelemente und des dadurch erzeugten Zwischeninhalts. In einer illustrativen Client-Server-Implementierung, z. B. einem Umcodierer-Proxy eines Servers, können die im Cache gespeicherten Informationen von mehreren Serverinstanzen genutzt werden, um einer redundanten Verarbeitung der Client-Anforderungen vorzubeugen.

Es ist demnach eine spezielle Aufgabe der vorliegenden Erfindung, Programmelemente in einem komplexen Softwaresystem zusammenzufassen, indem ein Gesamtausgang im Cache gespeichert wird, so dass Berechnungen nicht wiederholt werden und ein unnötiges und zu häufiges Caching vermieden wird. Es ist eine besondere Aufgabe der Erfindung, diesen Caching-Mechanismus in der Domäne der Umcodierung von Daten aus dem Web bereitzustellen.

Es ist eine weitere Hauptaufgabe der Erfindung, einen Mechanismus bereitzustellen, mit dem ein Satz von zusammengehörigen Umcodierern für Caching-Zwecke in einer Gruppe zusammengefasst werden kann. Als Anschauungsbeispiel dient eine Gruppe von zusammengehörigen Umcodierern, die einen Satz von Software-Routinen darstellen, welche Bilder eines gegebenen Bildformats (z. B. .gif) in ein oder mehrere andere Bildformate (z. B. .png, .jpeg, oder ähnliche) umcodieren. Ein anderes Beispiel einer Gruppe von zusammengehörigen Umcodierern sind Umcodierer, die Daten von einem Datenformat in ein anderes Datenformat konvertieren. Zum Zwecke des intermediären Caching entsprechend der vorliegenden Erfindung können die einzelnen Umcodierer in einer Gruppe also eine gegebene Beziehung zueinander haben.

In einem besonderen Ausführungsbeispiel wird eine Reihe von Umcodierern, die in einem Umcodierungs-Framework eingesetzt werden und eine Reihe von Präferenzkategorien (z. B. bestimmte Netzwerk-, Benutzer- oder Gerätepräferenzen) gemeinsam nutzen, in einer Gruppe zusammengefasst, um die Häufigkeit des intermediären Caching im Framework zu reduzieren. Es wird also nicht der Ausgang eines jeden Umcodierers, sondern nur der Gruppenausgang im Cache gespeichert.

Entsprechend einem anderen Merkmal der vorliegenden Erfindung wird eine Gruppe von zusammengehörigen Umcodierern vorzugsweise von einem Systemadministrator definiert. Indem man dem Administrator die Kontrolle über die Granularität des intermediären Caching ermöglicht, wird die System-Gesamt- Performanz über viele Client-Anforderungen verteilt und dadurch maximiert.

Mit der vorliegenden Erfindung kann ein Caching-Mechanismus in einem komplexen Softwaresystem benutzerkonfigurierbar erweitert werden, indem optimale intermediäre Cachingpunkte eingerichtet werden. Diese werden von Programmgruppen definiert, die für lange Berechnungen verwendet werden. Hierdurch werden die Raum- und Zeitressourcen innerhalb des Systems miteinander in Einklang gebracht.

In der obigen Beschreibung wurden einige der mehr zweckdienlichen Aufgaben und Vorteile der vorliegenden Erfindung angesprochen. Diese sind als reine Anschauungsbeispiele für einige der herausragenden Merkmale und Anwendungen der Erfindung zu betrachten. Viele andere vorteilhafte Ergebnisse können erzielt werden, wenn die beschriebene Erfindung auf andere Weise eingesetzt wird, oder wenn die Erfindung, wie nachstehend beschrieben, modifiziert wird. Dementsprechend werden andere Aufgaben und ein umfassenderes Verständnis der Erfindung anhand der folgenden ausführlichen Beschreibung des bevorzugten Ausführungsbeispiels deutlich.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Ein umfassenderes Verständnis der vorliegenden Erfindung sowie ihrer Vorteile erhält man aus der nachstehenden ausführlichen Beschreibung in Verbindung mit den beiliegenden Zeichnungen. Es zeigt:

Fig. 1 ein Blockdiagramm, das ein Umcodierungs-Backbone veranschaulicht, wie es für die Registrierung, das Laden, die Initialisierung und die Verwaltung eines Satzes von Umcodierern eingesetzt werden kann;

Fig. 2 ein vereinfachtes Blockdiagramm eines Gruppenadministrationsmechanismus der vorliegenden Erfindung;

Fig. 3 einen repräsentativen Dialog einer graphischen Benutzeroberfläche, mit dem ein Systemadministrator gegebene Umcodierer entsprechend der vorliegenden Erfindung einer oder mehreren Gruppen zuweisen kann;

Fig. 4a ein Blockdiagramm einer Teilschicht einer WBI- Clientsitzung, in der die vorliegende Erfindung implementiert werden kann;

Fig. 4b ein Blockdiagramm einer Teilschicht einer WBI- Transaktions-Sitzung, die in Verbindung mit der Teilschicht der Clientsitzung aus Fig. 4a verwendet wird;

Fig. 5 ein Blockdiagramm eines komplexen Softwaresystems, das eine Vielzahl von Programmen veranschaulicht, die sequentiell und parallel arbeiten;

Fig. 6, wie eine Gruppe von Programmelementen zur Wiederverwendung zusammengefasst wird, gemäß der vorliegenden Erfindung; und

Fig. 7 ein anderes Beispiel der Grundsätze der vorliegenden Erfindung im Zusammenhang mit einer Web- Umcodierungsanwendung.

AUSFÜHRLICHE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS

Als kurze Hintergrundinformation und unter Bezugnahme auf Fig. 1, die vorliegende Erfindung kann in einem Umcodierungs-Backbone 100 implementiert werden, in dem einzelne Umcodierer 102a-102n installiert sind und verwaltet werden. Ein bekanntes Umcodierungs-Backbone ist WeB Intermediaries ("WBI" oder webby). In WBI wird ein gegebener Umcodierer manchmal als MEG bezeichnet, womit die jeweilige Funktion gekennzeichnet wird (z. B. Anforderungsmodifizierer, Inhaltseditor, Inhaltsgenerator), die von dem Umcodierer ausgeführt wird. Im typischen Fall umfasst ein Umcodierer eine Reihe von Software-Routinen. Das Umcodierungs-Backbone 100 lässt sich in unterschiedlicher Weise einfach implementieren, beispielsweise als selbständiger Proxy- Server, als verwaltetes Java-Servlet in einer Web- Serveranwendung (z. B. IBM WebSphere), die für alle Anforderungen registriert ist, als aufrufbarer Dienst (über eine direkte API), oder als von jeder serverseitigen Anwendung aufrufbares Enterprise Java Bean (EJB). Die nun folgende Beschreibung erfolgt zwar in Zusammenhang mit einem WBI-basierten Umcodierungs-Backbone, ist jedoch nicht als Einschränkung der vorliegenden Erfindung zu betrachten. Die im folgenden beschriebenen Konzepte sind voneinander trennbar und können in einer anderen Servlet-basierten Umgebung oder in anderer Form direkt in einem Serverprogramm oder als Plugin eines solchen Programms codiert sein.

Bezugnehmend auf Fig. 1; ein gegebener Umcodierer 102 wird in dem Backbone von einem Administrator entweder statisch (z. B. in einer Eigenschaften-Datei 104) oder dynamisch (über eine Konsole 106 am Server) registriert. Alternativ kann der Umcodierer über eine externe Java-basierte GUI registriert werden. Nach der Registrierung werden ein oder mehrere Umcodierer bei der Initialisierung des Backbone geladen (d. h., wenn das Backbone, je nach Konfiguration, aus einer Befehlszeile gestartet wird, ein Servlet-Wrapper initialisiert wird, usw.) Nachdem die einzelnen Umcodierer geladen sind, kann das Backbone 100 die Umcodierer über die Schnittstellen 114 abfragen.

Ein intermediäres Caching von Daten im WBI-Framework ist wünschenswert, wenn dieses Caching sich entsprechend mit der Zeit in Einklang bringen läßt, die zur Erzeugung und Sicherung der Zwischendaten benötigt wird. Die vorliegende Erfindung löst dieses Problem, indem sie bestimmte MEGs zu einer oder mehreren MEG- (oder Umcodierer-)-Gruppen zusammenfasst. Anstatt die Ausgänge eines jeden MEG in einer gegebenen Gruppe im Cache zu speichern, wird nur der endgültige Ausgang zwischengespeichert. Fig. 2 zeigt einen bevorzugten Mechanismus, der für die Bereitstellung dieser Gruppenfunktionen entsprechend der Erfindung eingesetzt werden kann.

Insbesondere ist ein Gruppenadministrationsmanager 200 für das Zusammenfassen von MEGs zu MEG-Gruppen verantwortlich. Eine Reihe von MEG-Gruppen kann entsprechend einer Reihe von in der Datenbank 202 gespeicherten Ausführungsprioritäten ausgeführt werden. Weiter können einer gegebenen MEG auch eine Reihe von Abhängigkeiten zugeordnet sein, z. B. von welchen Netzwerkpräferenzen, welchen User-Präferenzen, welchen Gerätepräferenzen die MEG abhängig ist und so weiter. Repräsentative Netzwerkpräferenzen enthalten beispielsweise unterstützte und nicht unterstützte Erweiterungen, Bilder, Komprimierungsquelle und ähnliches. Zu den repräsentativen User-Präferenzen gehört eine Text/Bild-Link-Präferenz, ein Typ der gewünschten Quellenkomprimierung, wie Bilder angeordnet werden, bevorzugte Bildskalierungsfaktoren oder ähnliches. Zu den repräsentativen Gerätepräferenzen gehören unterstützte und nicht unterstützte Formate, Gerätetypen, gewünschte Inhaltstypen und ähnliches. Die Abhängigkeiten werden, vorzugsweise als (Code, Wert)-Paare, in einer Datenbank 204 gespeichert.

Wenn die Vorteile der Caching-Techniken der Erfindung genutzt werden sollen, kann ein Plugin-Schreibsystem die Präferenzinformation beim Bearbeiten der MEG durch den Autor bereitstellen. Der Administrator, der die MEG installiert, verwendet dann eine Schnittstelle 206 des Gruppenadministrationsmanagers 200, um die MEG einer gegebenen Gruppe zuzuweisen, um zu kennzeichnen, ob der Ausgang einer bestimmten Gruppe im Cache gespeichert werden soll, oder nicht, um die Reihenfolge der Ausführung der MEGs innerhalb einer gegebenen Gruppe zu definieren, um die Reihenfolge der Ausführung der MEG-Gruppen zu definieren, und so weiter. Die Schnittstelle 206 kann auch verwendet werden, um neue Gruppen zu erzeugen, um die Präferenzen einer gegebenen MEG zu verändern oder zu modifizieren, und ähnliches. Die Schnittstelle 206 kann eine graphische Benutzerschnittstelle (GUI), eine Befehlszeilen- Schnittstelle, oder eine andere passende Implementierung sein. Eine repräsentative GUI-Implementierung wird im folgenden ausführlich beschrieben.

In dem bevorzugten Ausführungsbeispiel der Erfindung werden MEGs mit verwandten Funktionen in einer MEG-Gruppe zusammengefasst. Auf diese Weise werden Programmelemente innerhalb des Softwaresystems leicht nutzbar gemacht. Bei einer gegebenen Gruppe von miteinander verwandten MEGs kann es sich also beispielsweise um diejenigen Plugins handeln, die ein Bildformat in ein anderes umwandeln, z. B. .gif in .png oder .jpeg, um Plugins, die einen Datentyp in einen anderen umwandeln, z. B. AFP (Advanced Function Printing Language) in SVG (Scalable Vector Graphics, eine XML 2D Graphiksprache nach dem W3C Standard), Postscript in HTML oder andere geeignete Beziehungen. Verwandte MEGs können solche sein, die Datentypen unabhängig von den Gerät-, User- oder Netzwerkpräferenzen umwandeln, oder solche, die eine Dokumentenauszeichnungssprache in eine andere umwandeln. Eine Gruppe kann MEGs umfassen, die Präferenzkategorien, gegebene Präferenzen oder ähnliches gemeinsam nutzen. Eine weitere Art von MEG-Gruppe können verschiedene MEGs sein, die eine Dokumentobjektmodelldarstellung (DOM-Darstellung) mit einem gegebenen Inhalt im Rahmen der W3C DOM-Richtlinien erzeugen. Die vorliegende Erfindung ist natürlich im Hinblick auf eine gegebene MEG-Gruppe nicht auf einen bestimmten Beziehungstyp beschränkt. Bezugnehmend auf Fig. 2; um die Funktionen der MEG-Gruppe zu unterstützen, liefert eine MEG eine gegebene Information mit den folgenden Methoden an den Gruppenadministrationsmanager:

• a) String getGroup() - rufe logischen Namen der Gruppe ab, zu der die MEG gehört;
• b) String getDependencies() - rufe logische Namen der Kategorien ab, von denen diese MEG abhängig ist; und
• c) boolean isNeverCached() - möglicher Platzhalter, um die Fähigkeit der besitzenden Gruppe zum Caching zu optimieren.

Die folgenden Methoden werden dann dem Ausführungsprozessor in dem Umcodierungsdienst bereitgestellt:

• a) Enumeration enumerateGroups();
• b) StringgetDependenciesForGroup() - erzeugt eine Vereinigung aller Abhängigkeiten, die von den MEGs in der Gruppe zurückgemeldet wurden;
• c) ExecuteMEGLoop(Group, Requestobject)

Immer dann, wenn Enumeration erscheint, kann es sich um ein Objekt handeln, das seine eigene Enumeration wrappert oder implementiert. Wenn die Gruppenfunktionalität eingesetzt wird, sollte der Administrator außerdem sicherstellen, dass die erste ausgewählte Gruppe eine Antwort (d. h., einen Ausgang) erzeugt. Dies ist eine Standardvoraussetzung.

Um diese Funktionen zu implementieren, wird eine registerAdmin(Admin)-Methode in dem Umcodierungsdienst zu der Proxy-Klasse hinzugefügt, um eine Mitteilung über die administrative Information zu erhalten. Die Caching- und Sitzungsverwaltungsimplementierung von Run.java (wird nachfolgend beschrieben) erzeugt Proxy-Lade-Plugins (aber keine Teilschichten) aus den Eigenschaften-Dateien. Dann wird eine Teilschicht erzeugt (die auch Admin verwaltet), und diese Teilschicht wird als Administrator für das WBI-Backbone sowie als Teilschicht für den Proxy registriert. Die Teilschicht erhält eine Mitteilung über die MEG- Registrierungen und gibt die Information an einen Ausführungsprozessor weiter, um, unter Anwendung der oben beschriebenen Methoden, die entsprechenden Gruppierungen vorzunehmen. Wenn er abgefragt wird, meldet der Gruppenadministrationsmanager ein Enumerationobjekt zurück, und zwar enumerateReverseOrderedGroups(), bei dem die letzte auszuführende Gruppe die erste auf der Liste ist.

Entsprechend einem Ausführungsbeispiel der vorliegenden Erfindung werden die Gruppenprioritäten also vorzugsweise vom Administrator definiert und die MEGs werden während der Initialisierung an ihrer getGroup()-Schnittstellenmethode aufgerufen, um den logischen Gruppennamen für die Gruppe zu holen, zu der sie gehören. Die Gruppen erhält man mit der hasMoreElements()-Methode und der nextElement()-Methode.

Ein durchschnittlicher Fachmann wird erkennen, dass die MEGs durch den Gruppenadministrationsmechanismus alternativ auch dynamisch in ihre Gruppen gerufen werden können. Insbesondere kann eine gegebene MEG-Gruppe "on-the-fly" (also dynamisch) definiert und erzeugt werden, da sich der Umcodierungsdienst an verschiedene Betriebsbedingungen anpasst.

Fig. 3 zeigt eine repräsentative GUI-Schnittstelle, die zur Implementierung der Gruppenadministrationsfunktionen der vorliegenden Erfindung eingesetzt werden kann. Das zur Veranschaulichung gezeigte Anzeigentableau ist ein Gruppenadministrations-Tableau 300, das ein Anzeigefeld 'Gruppenreihenfolge auswählen', 302, ein Anzeigefeld 'Umcodierer zuweisen', 304, und ein Anzeigefeld 'Verfügbare Umcodierer', 306, enthält. Der Administrator weist mit Hilfe eines herkömmlichen Drag-and-Drop-Mechanismus (oder einer anderen geeigneten User-E/A-Technik) die verfügbaren Umcodierer den Gruppen zu und bestimmt dann die Reihenfolge der Gruppen für die Ausführung. Wie bereits oben erwähnt kann die Zuordnung von Umcodierern zu Gruppen auch dynamisch erfolgen. In dem Anschauungsbeispiel wird die Gruppe C zur Ausführung vor den Gruppen A und B plaziert. Gruppe C umfasst Umcodierer, die unabhängig von Geräte-/User- /Netzwerkpräferenz von AFP entweder nach HTML oder SVG konvertieren. Gruppe A hat nur einen einzigen Umcodierer, der von SVG nach HTML konvertiert. Gruppe B berücksichtigt Geräte-/User-/Netzwerkpräferenzen und reduziert HTML zu WML und HTML zu VoxML (Voice Markup Language, ein anderer XML- Standard). Die verfügbaren Umcodierer (die als 'ungruppiert' gekennzeichnet wurden) umfassen einen Umcodierer, der AFP in Postscript konvertiert, einen Umcodierer für HTML zu PvC HTML (für universelle Rechner, die nicht über die volle HTML- Funktionalität verfügen) und einen Umcodierer für Xerox zu AFP. Natürlich dienen alle oben genannten Umcodiererfunktionen sowie ihre repräsentativen Gruppierungen nur der anschaulichen Darstellung. Die Gruppenadministrationsfunktion der Erfindung ist nicht beschränkt auf eine bestimmte Umcodierungsfunktion, auf eine bestimmte MEG-Gruppe oder bestimmte Gruppenkonstituenten.

Der Benutzerdialog umfasst auch ein Schaltfeld 'Neue Gruppe erstellen', 308. Wenn dieses Schaltfeld angeklickt wird, öffnet sich ein Dialog (nicht dargestellt), der eine Liste mit den verfügbaren Umcodierern enthält. Aus dieser Liste kann der Administrator eine benutzerdefinierte Gruppe auswählen und dann die Ergebnisse sichern. Bei Auswahl eines gegebenen Umcodierers (z. B. aus dem Gruppendialogtableau 300 der Fig. 3 oder aus dem Dialog 'Neue Gruppe erstellen') wird von der administrativen Schnittstelle ein Umcodiererdialog (nicht dargestellt) geöffnet, in dem der Administrator gegebene Eigenschaften des Umcodierers definieren, Netzwerk-, User- oder Geräteabhängigkeiten modifizieren und ähnliche Operationen durchführen kann.

Gemäß der vorliegenden Erfindung soll das intermediäre Caching von Gruppenausgangsdaten die Wiederverwendung von MEGs in einem Server mit Umcodierungsdienst vereinfachen. Es soll nun zur Veranschaulichtung ein WBI-Framework beschrieben werden, in dem die vorliegende Erfindung eingesetzt wird.

Die Fig. 4a-4b veranschaulichen einen Umcodierungsdienst, der z. B. als Web-Server eingesetzt werden kann. Mit diesem Service ist die Verwaltung und das Caching von Clientsitzungen im Rahmen eines WBI-basierten Backbone möglich. Zu diesem Zweck werden zwei spezialisierte Teilschichten eingesetzt, die als Clientsitzungs-Teilschicht bzw. als Umcodierungssitzungs-Teilschicht bezeichnet werden. Allgemein ausgedrückt hört eine Teilschicht einen oder mehrere Ports auf ankommende Anforderungen von einem Client (beispielsweise einem Browser) ab und gibt diese Anforderungen über das Backbone und die registrierten Plugins weiter, von denen eine an den Client zurückzumeldende Antwort erzeugt wird. Wie man sehen wird, nutzt eine gegebene Teilschicht einen Caching-Proxy, um sowohl Umcodierungs- Zwischenschritte als auch den endgültigen Ausgang im Cache zu speichern, so dass es nicht notwendig ist, bei jeder Anforderung einer gegebenen Ressource einen Ausgang neu zu erzeugen. Zu diesem Zweck werden die Gruppen-Caching- Techniken der vorliegenden Erfindung eingesetzt.

Die Clientsitzungs-Teilschicht 400, die in Fig. 4a dargestellt ist, ist für das Identifizieren von Clientsitzungen verantwortlich. Clientsitzungen können beispielsweise durch Plazieren von Cookies oder durch eine andere Implementierung identifiziert werden. Die Teilschicht für die Umcodierungssitzung, 450, die in Fig. 4b dargestellt ist, ist sowohl für das Caching der Umcodierungs- Zwischenschritte als auch des endgültigen Ausgangs verantwortlich. Vorzugsweise wird für diese Funktionen ein vorhandener Caching-Proxy 402 verwendet, da bereits viele dieser Proxies verfügbar sind. Bekanntlich arbeitet ein Caching-Proxy mit einem Pull-Mechanismus. Im einzelnen wird eine Ressource vom Cache angefordert und, falls verfügbar, zurückgemeldet; andernfalls holt der Cache die Ressource selbst und meldet sie dann dem Client. Dieses Verhalten erfordert, dass alle Anforderungen einer Ressource über den Cache laufen.

In einer bevorzugten WBI-Umgebung, wie sie beispielsweise in den Fig. 4a-4b dargestellt ist, wird ein URL- Umschreibsystem in Antwort auf eine gegebene Client- Anforderung verwendet. Wenn ein URL mit einer ursprünglichen Anforderung an der Clientsitzungs-Teilschicht 400 ankommt, wird dieser URL so modifiziert, dass er auf die Teilschicht der Umcodierungssitzung, 450, zeigt. Der umgeschriebene URL codiert den ursprünglichen URL sowie alle Umcodierer (d. h. MEGs), die zur Erfüllung der Anforderung laufen müssen. Die Teilschicht 400 der Clientsitzung fordert dann diesen umgeschriebenen URL über den Cache 402 an (eine proxifierte Anforderung). Bei einem Cache-Miss (z. B. wenn die Ressource zum ersten Mal angefordert wird), ruft die Teilschicht 450 der Umcodierungssitzung die richtigen MEGs auf, um die Antwort zu erzeugen. Weil die Antwort über den Cache 402 erfolgte, wird die von der Teilschicht 450 der Umcodierungssitzung erzeugte Antwort im Cache gespeichert und bei allen nachfolgenden Anforderungen für diese Ressource direkt vom Cache zurückgemeldet (unter Beachtung der für den Cache gültigen Ablaufregeln).

Die Teilschicht 400 der Clientsitzung und die Teilschicht 450 der Umcodierungssitzung arbeiten zusammen, um eine Umcodierung des Inhalts über das WBI-Backbone durchzuführen, und den Ausgang der Umcodierung zur Wiederverwendung bei späteren Anforderungen im Cache zu speichern. Vorzugsweise verwenden sowohl die Teilschicht der Clientsitzung als auch die Teilschicht der Umcodierungssitzung das HTTP-Protokoll.

Bezugnehmend auf Fig. 4; die Teilschicht 400 der Clientsitzung umfasst einen Protokollinterpretierer 404 an ihrem Eingang und einen Protokollcodierer 406 an ihrem Ausgang. Der Protokollinterpretierer 404 hört einen dedizierten Port auf HTTP-Anforderungen von Clients ab und arbeitet mit dem Sitzungsmanager 408 zusammen, um Clientsitzungen herzustellen und/oder bereits bestehende Clientsitzungen zu erkennen. Die Bezeichnung (a) in der Figur weist darauf hin, dass der Protokollinterpretierer einen Client-Code bereitstellt, wenn er Teil des Protokolls ist. Wird kein Sitzungscode bereitgestellt, wird eine Standardsitzung verwendet. Die Teilschicht der Clientsitzung umfasst außerdem zwei Regelmaschinen (RMs) 409 und 410. Die Teilschicht gibt die Anforderungen im WBI-Backbone über einen registrierten Anforderungsinterpretierer weiter.

Wenn bei der Teilschicht eine Anforderung eingeht, erzeugt diese RequestHandle- und ResponseHandle-Objekte. Das Objekt RequestHandle kapselt den InputStream vom Socket 405, der erzeugt wurde, als die Teilschicht die Verbindung (serversocket.accept()) akzeptierte, und den ProtocolInterpreter ein. Das Objekt ResponseHandle kapselt den OutputStream des Socket und den ProtocolEncoder ein. Das Backbone nutzt den Protokollinterpretierer 402, um den InputStream der Anforderung in eine Form zu 'interpretieren', die von den registrierten MEGs genutzt werden kann. Wenn der Protokollinterpretierer 402 in dem InputStream ein Cookie oder ein anderes Sitzungserkennungszeichen findet, fordert er den Sitzungsmanager 408 auf, ein Sitzungsobjekt zurückzumelden, das die Clientsitzung repräsentiert. Die Bezeichnung (b) in der Figur weist darauf hin, dass der Client-Code von einer Cookie-Implementierung abgeleitet sein kann. Die Bezeichnung (f) weist darauf hin, dass das Sitzungsobjekt zu den anforderungsspezifischen Daten hinzugefügt werden kann, die von dem Request-Handle-Objekt gepflegt werden. Nachdem eine bereits bestehende Sitzung, falls vorhanden, erkannt wurde, fragt die Teilschicht der Clientsitzung den Gruppenadministrationsmanager 412 und seine zugeordnete Datenbank 414 nach den Gruppen- Ausführungsprioritäten.

Wie bereits weiter oben beschrieben, werden die Gruppenprioritäten vorzugsweise vom Administrator definiert. Wie durch die Bezeichnung (e) wiedergegeben wird, werden gegebene MEGs während der Initialisierung an ihrer GetGroup()-Schnittstellenmethode aufgerufen, um den logischen Namen einer Gruppe abzurufen, zu dem sie gehören. Der Gruppenadministrationsmanager 412 meldet die MEG-Gruppen zurück, vorzugsweise in umgekehrter Reihenfolge; das bedeutet, dass die erste zurückgemeldete Gruppe die letzte Gruppe ist, die ausgeführt wird. Für jede zurückgemeldete Gruppe fragt die Teilschicht der Clientsitzung ein Präferenzsystem 416 und seine zugehörige Datenbank 418 ab, um eine Liste der Abhängigkeiten (Präferenzwerte) zu bekommen.

Diese Abhängigkeiten, bei denen es sich, wie weiter oben beschrieben, vorzugsweise um (Code, Wert)-Paare handelt, werden dann von dem Präferenzsystem 416 zu einer einzigen Kette komprimiert. Die Bezeichnung (c) in der Figur weist darauf hin, dass Präferenzcodes gewöhnlich über alle Serverinstanzen homogen sind. Diese Abhängigkeiten sind vorzugsweise die Vereinigung aller Abhängigkeiten der einzelnen MEGs innerhalb der Gruppe, zu der die MEGs gehören. In einem repräsentativen Ausführungsbeispiel werden diese Abhängigkeiten vom Präferenzsystem über die Schnittstellenmethode getDependencies() abgerufen. Die Bezeichnung (i) in der Figur weist auf eine optionale Prüfung des Clientsitzungsobjekts an dem angegebenen Punkt hin.

Nachdem alle Gruppen und ihre Abhängigkeiten vorliegen, führt der Generator 418 eine Umschreibung des URL durch. Der neue URL enthält die ursprüngliche Anforderung, die MEG-Gruppen und ihre Abhängigkeiten, und ein Cookie (oder ein anderes Sitzungserkennungszeichen), wenn vom Sitzungsmanager 408 ein solches angegeben wurde. Dieser neue URL wird dann von der Teilschicht 450 der Umcodierungssitzung (in Fig. 4b) über die Cache-Schnittstelle 420 angefordert. Die Bezeichnung (d) weist darauf hin, dass der Generator 418 vorzugsweise eine abstrakte Klasse, beispielsweise Bytestore, verwendet, um das Caching beweglicher Fenster und andere Funktionen zu ermöglichen.

Der neue URL kann beispielsweise folgende Form aufweisen:
GET http://TSS:8000/www.cnn.com/group1/compressed_data1/group 2/compressed_data2.

Wenn sich die Ressource dieses URL momentan im Cache 402 befindet, wird die Ressource direkt vom Cache zurückgemeldet und an den ProtocolEncoder 406 weitergegeben, wo sie codiert und über den Outputstream in ResponseHandle an den Client zurückgegeben wird. Befindet sich die Ressource jedoch momentan nicht im Cache, leitet der Cache 402 die Anforderung an die Teilschicht 450 der Umcodierungssitzung weiter. Wie noch zu sehen sein wird, gibt die Teilschicht 450 dann die Anforderung an das Backbone weiter, um die richtige Antwort zu erzeugen.

Wenn eine Anforderung dann schließlich komplett ist und von der Teilschicht der Umcodierungssitzung zurückgemeldet wird, kann in der Antwort ein zu speicherndes Cookie enthalten sein. In diesem Fall gibt die Teilschicht 400 der Clientsitzung das Cookie an den Sitzungsmanager 408 weiter, so dass dieser Client in eine Sitzung eingebunden werden kann. Spätere Anforderungen von diesem Client würden dann vom Sitzungsmanager 408 erkannt, wie oben beschrieben.

In Fig. 4 enthält die Teilschicht der Clientsitzung einen anderen Umcodierungseditor 422. Wie durch die Bezeichnung (g) angezeigt wird, kann der Umcodierer verwendet werden, um optionale Client-Cachingregeln zu implementieren und zu verwalten, die sich von den Cachingregeln eines Ursprungsservers unterscheiden. Die Client-Cachingregeln können von einem Administrator aufgestellt werden. Hierdurch ist eine erneute Umcodierung mit einer gegebenen Zeitgranularität möglich, die auf der Umcodierungs-Proxy- Ebene gesteuert wird.

Bezugnehmend auf Fig. 4b; die Teilschicht 450 der Umcodierungssitzung hört einen dedizierten Port auf Anforderungen von der Teilschicht 400 der Clientsitzung ab. Wie weiter oben bereits erwähnt, besteht die Funktion der Teilschicht 450 der Umcodierungssitzung darin, die Anforderung durch das WBI-Backbone weiterzugeben, um die gewünschte Umcodierung zu erreichen. Wie noch zu sehen ist, nutzt die Teilschicht der Umcodierungssitzung viele Komponenten der Teilschicht der Clientsitzung.

Bei einer Eingangsanforderung der oben beschriebenen Form stellt die Teilschicht 450 der Umcodierungssitzung fest, dass der URL mehr als einen Gruppennamen enthält. Die Teilschicht baut daher zuerst einen neuen URL auf, vorzugsweise durch Entfernen des Namens und der Daten der letzten Gruppe. Der daraus resultierende URL sieht wie folgt aus:
GET http://TSS:8000/www.cnn.com/group1/compressed_data1. Die Teilschicht fordert dann diesen neuen URL über die Cache- Schnittstelle an. Solange ein Cache-Miss vorliegt, fordert die Teilschicht der Umcodierungssitzung in der gleichen Weise rekursiv URLs über den Cache 402 an. Wenn es sich hierbei um die erste Anforderung für diesen speziellen Satz von MEG- Gruppen handelt, kommt es nicht zu einem Cache-Hit. Sobald die Teilschicht also feststellt, dass der URL nur eine einzige MEG-Gruppe/ein einziges Datenpaar enthält, sendet sie die Anforderung in das Backbone, um den Inhalt zu erzeugen. Weil die Anforderung ursprünglich jedoch über die Cache- Schnittstelle 402 erfolgte, wird der von dieser letzten MEG- Gruppe zuletzt zurückgemeldete OutputStream im Cache gespeichert. Er steht als Eingang für die vorherige MEG- Gruppe zur Verfügung. Wenn die Kette abgewickelt wird, wird jeder Umcodierungs-Zwischenschritt (d. h., der Ausgang einer gegebenen MEG-Gruppe) im Cache gespeichert und steht somit zur Verfügung, falls nachfolgende Anforderungen denselben Ausgang benötigen. Wie durch Bezeichnung (h) angegeben wird, ist dieser Schritt eine rekursive Anforderung an die Umcodierungs-Teilschicht, die immer noch auf den Cache zugreift und entweder auf prev = null kommt und sich auflöst, oder ein Zwischenergebnis aus dem Cache erhält und sich von diesem Punkt an auflöst. Wie durch Bezeichnung (j) angezeigt wird, wenn Generatoren Ursprungsdaten über HTTP abrufen, sollten sie dies über die Cache-Schnittstelle tun, so dass auch die ursprünglichen (d. h. die nicht umcodierten) Ressourcen im Cache gespeichert werden. In Fig. 4b ist die Raute "1", die mit der Bezugszahl 460 bezeichnet wurde, ein Entscheidungspunkt, der den nachfolgenden Pfad durch das System bestimmt. Wenn der endgültige Ausgang erzeugt wurde, kann der ProtocolEncoder aufgerufen werden, um ein Ergebnis an den Anforderer zurückzugeben. Wie bereits oben beschrieben, war der Anforderer in diesem Fall tatsächlich die Teilschicht 400 der Clientsitzung. Die Teilschicht der Clientsitzung gibt dann die Ressource an den realen Client, nämlich an den anfordernden Client-Browser. Hiermit ist die Verarbeitung abgeschlossen.

Der Schutzbereich der vorliegenden Erfindung lässt viele Varianten zu. Wenn beispielsweise von einer MEG innerhalb einer Gruppe eine Ausführungsunterbrechung verursacht wird, kann ein Controller für die Ausführung von Anforderungen andere MEGs in dieser Gruppe überspringen. Die Funktionen der Gruppenadministration können außerdem erweitert werden, um Gruppenregeln vorzukonfigurieren, so dass unter bestimmten Umständen ganze MEG-Gruppen übersprungen werden können.

Gemäß der vorliegenden Erfindung werden also Software- Elemente in Gruppen zusammengefasst, wobei der Ausgang der Gruppe zur späteren Wiederverwendung im Cache gespeichert wird. Das Zusammenfassen von Software-Elementen in Gruppen ist wünschenswert, um weniger Platz im Cache zu verbrauchen und gleichzeitig sicherzustellen, dass der Cache nicht überlastet wird. Der Ausgang einer gegebenen Gruppe wird im Cache gespeichert und in späteren Rechenvorgängen wiederverwendet. Es wird nun ein weiteres Anschauungsbeispiel des Erfindungskonzepts unter Bezugnahme auf die Fig. 5-7 beschrieben.

Fig. 5 zeigt ein herkömmliches komplexes Softwaresystem 500.

Zur anschaulichen Darstellung sind die Eingangsdaten A 502 der Eingang in das Programm A 504. Der Ausgang G 520 ist der endgültige Ausgang des Systems. Programm A 504 erzeugt als Dateneingang die Daten AB 505 und die Eingangsdaten AD 507 für das Programm B 506 bzw. das Programm D 508. Programm B 506 erzeugt die Daten BC 509 für Programm C 510. Programm C 510 und Programm D 511 erzeugen zusammen die Daten CDF 512 als Eingang in das Programm E 514. Programm E 514 erzeugt seinerseits die Daten EF 516 für Programm F 518. Programm F erzeugt den endgültigen Ausgang G 520.

In vielen Websituationen enthalten die Eingangsdaten 502 zwei Elemente, ein festes Element und ein variables Element. Die Eingangsdaten A können beispielsweise Daten von Webseiten sowie User-Präferenzen darüber enthalten, wie diese Webseitendaten für die Anzeige umcodiert werden sollen (z. B. ohne Bilder). Im typischen Fall sind die Webseitendaten ein festes Element und die User-Präferenzen sind variable Elemente. Fig. 6 zeigt das Computersystem der Fig. 5, in dem eine andere Gruppe variabler Elemente als Ersteingang verwendet wird. Als Anschauungsbeispiel sind die Eingangsdaten A* 602 der Eingang für das Programm A 604. Der Ausgang G* 620 ist der endgültige Ausgang des Systems. Programm A 604 erzeugt die Eingangsdaten AB 605 und die Eingangsdaten AD* 607 für Programm B 606 bzw. Programm D 608. Programm B 606 erzeugt die Daten BC 609 für Programm C 610. Programm C 610 und Programm D 608 erzeugen zusammen die Daten CD*F 612 als Eingang in das Programm E 614. Programm E 614 erzeugt seinerseits die Daten EF* 616 für Programm F 618. Programm F erzeugt den endgültigen Ausgang G* 620.

Wie anhand eines Vergleichs der Fig. 5-6 zu erkennen ist, werden die Programme B und C zweimal ausgeführt, obwohl ihr Eingang und Ausgang in beiden Operationen gleich ist. Wie bereits oben beschrieben wurde, wird mit der vorliegenden Erfindung diese redundante Ausführung dieser Programmelemente überflüssig, weil die Elemente in Gruppen zusammengefasst werden (wie durch die gestrichelte Linie in Fig. 6 angedeutet wird) und nur der Ausgang der gesamten Gruppe, nicht aber der Ausgang von Programm B und der Ausgang von Programm C, im Cache gespeichert werden.

Fig. 7 zeigt ein konkreteres Beispiel der vorliegenden Erfindung. In diesem Beispiel ist der Eingang 701 ein HTML- Dokument mit einem .gif-Bild. In Antwort auf eine erste Anforderung dieses Eingangs von einem Client ist der an den ersten User zurückgegebene Ausgang 703 ein PDF-Dokument mit einem .jpeg-Bild anstelle des .gif-Bildes. In Antwort auf eine zweite Anforderung von einem Client ist der an den zweiten User zurückgegebene Ausgang 705 ein SVG-Dokument mit dem .jpeg-Bild. In diesem Beispiel veranschaulicht die Gruppe 702 die Elemente, die für Caching-Zwecke zusammengefasst wurden, vorzugsweise unter Verwendung der weiter oben beschriebenen Gruppenadministrationsfunktionen. Die Gruppe 702 umfasst ein erstes Programmelement 704, welches das .gif- Bild analysiert, ein zweites Programmelement 706, welches das .gif-Bild in ein .png-Format konvertiert, und ein drittes Programmelement 708, welches das .png-Bild in ein .jpeg- Format konvertiert. Nur der Ausgang 707 der Gruppe (nämlich das dritte Programmelement 708) wird im Cache gespeichert und dann wieder verwendet, um die Antworten auf die einzelnen Clientanforderungen zu vereinfachen.

Wie bereits weiter oben beschrieben wurde, um die Gruppenadministration zu unterstützen, sollte den in dem Umcodierer-Framework verwendeten MEGs folgendes zugeordnet werden: ein logischer Gruppenname, zu dem eine MEG gehört, logische Namen von Kategorien, von denen eine MEG abhängt, und (optional) ein Hinweis, dass eine MEG niemals im Cache gespeichert wird (entweder weil sie personalisierte Daten enthält oder aus anderen sicherheitstechnischen Gründen). Vorzugsweise arbeitet MEG in Verbindung mit dem Gruppenadministrationsmechanismus. Der MEG-Autor sollte eine adäquate Dokumentation der MEGs bereitstellen, wenn er Plugins liefert, so dass vom Gruppenadministrator bei der Klassifizierung der MEGs intelligente Entscheidungen getroffen werden können.

Die vorliegende Erfindung hat gegenüber dem Stand der Technik zahlreiche Vorteile. Mit der vorliegenden Erfindung kann ein Caching-Mechanismus in einem komplexen Softwaresystem benutzerkonfigurierbar erweitert werden, indem optimale intermediäre Cachingpunkte eingerichtet werden. Diese werden von Programmgruppen definiert, die in langen Berechnungen verwendet werden, wodurch ein Ausgleich zwischen den räumlichen und zeitlichen Ressourcen in dem System geschaffen wird. Vorzugsweise werden MEGs abhängig davon in Gruppen zusammengefasst, ob die einzelnen MEGs zueinander eine bestimmte Beziehung haben, oder nicht. Diese besondere Beziehung kann sich auf Bildformate, Datenformate, Netzwerk-, Gerät- oder Userpräferenzen oder ähnlichen Kriterien beziehen.

Ein intermediäre Caching von Bild-Umcodierungen gemäß der vorliegenden Erfindung erhöht die System-Performanz beträchtlich. Vorgeschlagene MEG-Gruppierungen können Bildgruppen umfassen, wann immer dies geeignet erscheint, denn erst durch das Caching von Bildern werden im Betrieb des Umcodierungs-Frameworks signifikante Leistungsvorteile erzielt. Typischerweise machen Bilddaten einen wesentlichen Teil des Netzverkehrs aus (weit über 50%, möglicherweise bis zu 70%), wenn die Größe das entscheidende Kriterium ist. Aus dem Caching von Bildgruppen und ihrer Wiederverwendung bei der Umcodierung, entsprechend der Erfindung, lassen sich also signifikante Leistungsvorteile erzielen.

Die vorliegende Erfindung kann mit "pull"-Caching-Lösungen Dritter (z. B. Squid, WTE und ähnliches) verwendet werden, so dass User bereits vorhandene Caching-Software nutzen können. Wenn Sie im WBI-Framework eingesetzt werden, müssen bereits vorhandene Umcodierer nicht modifiziert werden, um zu einem endgültigen Ausgang einer Gruppe derartiger Umcodierer zu gelangen. Diese Cachingpunkte werden tatsächlich ohne Overhead oder Aufwand hinzugefügt, indem man die neuen steckbaren Komponenten einfach auf der WBI-"Kern"-Codebasis installiert/konfiguriert. Die Entwickler von Umcodierern, die den Cachingentwurf verwenden möchten, müssen also keine zusätzlichen Schnittstellen in ihrem Code bereitstellen, damit diese Cachingpunkte entstehen. Vielmehr erhält man durch eine einfache Konfiguration über die Administrations- Tableaus und zusätzliche Plugin-Installationsschnittstellen auf bekannten WBI-Plugins genügend Informationen, um diese Caching-Punkte zu spezifizieren.

Ein gegebener Umcodierer umfasst Software, also eine Reihe von Programmbefehlen, die in einem Prozessor ausgeführt werden können. Ein repräsentativer Prozessor ist x86-, Pentium-, PowerPC®- oder RISC-basiert und hat somit ein zugeordnetes Betriebssystem. Eine repräsentative Rechenplattform ist ein IBM S390 und ein AS400.

Die vorliegende Erfindung kann in einer herkömmlichen Client- Server-Rechenumgebung implementiert werden. Eine gegebene Client-Maschine und der Server können über das öffentliche Internet, ein Intranet oder ein anderes Computernetzwerk miteinander kommunizieren. Falls gewünscht, können gegebene Kommunikationen über eine sichere Verbindung stattfinden. Beispielsweise kann ein Client mit dem Server über ein Netzwerk-Sicherheitsprotokoll kommunizieren, z. B. das Netscape-Protokoll Secure Socket Layer (SSL) oder ähnliches.

Ein repräsentativer Client ist ein Personalcomputer, ein Notebook-Computer, ein Internet-Gerät oder ein universelles Rechengerät (z. B. ein PDA oder ein Palmtop-Computer) auf x86-, PowerPC®- oder RISC-Basis. Der Client umfasst ein Betriebssystem, beispielsweise Microsoft Windows, Microsoft Windows CE oder PalmOS. Wie bereits oben erwähnt, enthält der Client eine Reihe von Internet-Tools, einschließlich eines Web-Browsers, beispielsweise Netscape Navigator oder Microsoft Internet Explorer, der eine Java Virtual Machine (JVM) und Unterstützung für Anwendungs-Plugins oder Hilfsanwendungen bietet.

Unter Bezugnahme auf Fig. 1; ein repräsentativer Web-Server ist ein IBM Netfinity Server, der einen RISC-basierten Prozessor 121, ein UNIX-basiertes Betriebssystem 123 und ein Web-Serverprogramm 125 umfasst. Auch geeignete E/A-Geräte 126 und Routinen sind vorhanden, um die oben beschriebenen Administrationsfunktionen zu vereinfachen. Natürlich kann auch jede geeignete Server-Plattform (z. B. Apache, WebSphere oder ähnliches) unterstützt werden. Der Server kann eine Anwendungsprogrammierschnittstelle (API) 129 umfassen, mit Möglichkeiten, die Kernfunktionen über Softwareprogramme zu erweitern oder anzupassen, einschließlich Plugins, CGI- Programme, Servlets und ähnliches.

Der Gruppenadministrationsmechanismus der vorliegenden Erfindung kann in einer in einem Prozessor ausführbaren Software implementiert werden, nämlich als ein Befehlssatz (Programmcode) in einem Codemodule, das in dem Direktzugriffsspeicher des Computers gespeichert ist. Der Befehlssatz kann in einem anderen Computerspeicher gespeichert werden, bis er vom Computer gebraucht wird, beispielsweise in einem Festplattenlaufwerk oder in einem herausnehmbaren Speicher, oder er kann über das Internet oder ein anderes Computernetzwerk heruntergeladen werden.

Obwohl die verschiedenen, hier beschriebenen Methoden in einem universellen Computer, der über die Software selektiv aktiviert oder neu konfiguriert werden kann, auf einfache Weise implementiert werden können, würde ein durchschnittlicher Fachmann auch erkennen, dass solche Methoden in der Hardware, in der Firmware oder in einer speziellen Vorrichtung ausgeführt werden können, die zur Durchführung der erforderlichen Schritte der Methode konstruiert wurden.

Ein durchschnittlicher Fachmann wird auch erkennen, dass die Caching-Technik der vorliegenden Erfindung für jedes Softwaresystem generalisiert werden kann, das über eine Vielzahl von objektbasierten Programmelementen verfügt. Die Erfindung ist demnach nicht auf ein WBI-Framework mit Umcodierern beschränkt.

Nachdem wir nun unsere Erfindung beschrieben haben, sollen diejenigen Merkmale, die wir als neu beanspruchen und mittels einer Patentschrift sichern möchten, in den folgenden Ansprüchen dargelegt werden.

Claims (24)

1. Verfahren zum Cachen in einem Softwaresystem, mit einer Vielzahl von Programmelementen, folgende Schritte umfassend:
Zusammenfassen einer Reihe von in Beziehung stehenden Programmelementen in einer Gruppe; und
Cachen des Gesamtausgangs der Gruppe nur bei Abschluss der Ausführung sämlticher der in Beziehung stehenden Programmelemente.

2. Verfahren nach Anspruch 1, bei dem die Vielzahl von Programmelementen Umcodierer umfasst und das Softwaresystem ein Web-Server mit einem Umcodierungsdienst ist.

3. Verfahren nach Anspruch 2, bei dem ein gegebener Umcodierer ein Anforderungsmodifizierer ist.

4. Verfahren nach Anspruch 2, bei dem ein gegebener Umcodierer ein Inhaltseditor ist.

5. Verfahren nach Anspruch 2, bei dem ein gegebener Umcodierer ein Inhaltsgenerator ist.

6. Verfahren nach Anspruch 1, bei dem jedes der zugehörigen Programmelemente in der Gruppe Bilder verarbeitet.

7. Verfahren nach Anspruch 1, bei dem jedes der zugehörigen Programmelemente in der Gruppe Daten verarbeitet.

8. Verfahren nach Anspruch 1, bei dem allen zugehörigen Programmelementen in der Gruppe eine gegebene Präferenzkategorie gemeinsam ist.

9. Verfahren nach Anspruch 1, bei dem allen zugehörigen Programmelementen in der Gruppe eine gegebene Präferenz gemeinsam ist.

10. Verfahren zum Cachen in einem Softwaresystem, mit einer Vielzahl von Programmelementen, folgende Schritte umfassend:
Zusammenfassen einer Reihe von Programmelementen in einer oder mehreren Gruppen;
in Antwort auf eine erste Anforderung von einem Client, selektives Cachen eines Gesamtausgangs einer Gruppe nur bei Abschluss der Ausführung aller Programmelemente in der gegebenen Gruppe; und
in Antwort auf eine zweite Anforderung von einem Client, Verwenden des Gesamtausgangs, um eine Antwort auf die zweite Anforderung von einem Client zu erzeugen.

11. Verfahren nach Anspruch 10, weiter umfassend folgenden Schritt: Kennzeichnen einer gegebenen Priorität für jede der ein oder mehreren Gruppen.

12. Verfahren nach Anspruch 11, weiter umfassend folgenden Schritt: Ausführen der einen oder mehreren Gruppen entsprechend der gegebenen Priorität.

13. Verfahren nach Anspruch 11, bei dem mindestens eine Gruppe eine Reihe von Präferenzwerten umfasst.

14. Verfahren nach Anspruch 13, bei dem die Präferenzwerte aus einer Reihe von Werten ausgewählt werden, die aus User-Präferenzen, Netzwerkpräferenzen und Gerätepräferenzen bestehen.

15. Verfahren, das auf einem Server betrieben werden kann, folgende Schritte umfassend:
in Antwort auf eine Client-Anforderung, Erzeugen eines URL, der eine Reihe von Umcodierungsgruppen kennzeichnet, wobei jede Umcodierungsgruppe eine Reihe von administratordefinierten Umcodierern umfasst;
Ausführen der Umcodierungsgruppen zur Erzeugung eines Ausgangsstroms; und
Cachen eines Ausgangs eines gegebenen Zwischen- Umcodierungsschritts, der von einem der Umcodierergruppen durchgeführt wird, zur späteren Wiederverwendung.

16. Verfahren nach Anspruch 15, bei dem die Umcodierungsgruppen entsprechend einer gegebenen Priorität ausgeführt werden.

17. Verfahren nach Anspruch 16, bei dem die gegebene Priorität benutzerdefiniert ist.

18. Verfahren nach Anspruch 15, bei dem jede der Umcodierungsgruppen eine Reihe von ihnen zugeordneten Präferenzwerten hat.

19. Verfahren nach Anspruch 18, bei dem die Reihe von Präferenzwerten eine Präferenz umfasst, die aus einer Netzwerkpräferenz, einer User-Präferenz und einer Gerätepräferenz ausgewählt wird.

20. Ein Computerprogrammprodukt in einem computerlesbaren Medium zum Einrichten intermediärer Caching-Punkte in einem Softwaresystem mit einer Vielzahl von Programmelementen, umfassend:
Mittel, um Sätze von gegebenen Programmelementen in einer oder mehreren Gruppen zusammenzufassen;
Mittel, um die Gruppen für die Ausführung zu priorisieren; und
Mittel, um einen Satz von Präferenzwerten für jede Gruppe zu definieren.

21. Ein Computerprogrammprodukt in einem computerlesbaren Medium zum Cachen von Daten in einem Softwaresystem mit einer Vielzahl von Programmelementen, umfassend:
Mittel, um einen Satz von zugehörigen Programmelementen zu einer Gruppe zusammenzufassen;
Mittel, die während der Verarbeitung einer Client- Anforderung aktiv werden, um einen Gesamtausgang des Satzes von zusammengehörigen Programmelementen zur späteren Wiederverwendung im Cache zu speichern, wobei ein einzelner Ausgang mindestens eines Satzes von zusammengehörigen Programmelementen in der Gruppe nicht im Cache gespeichert wird.

22. Ein Computersystem zum Bereitstellen eines Umcodierungsdienstes, folgendes umfassend:
einen Satz von Programmelementen;
einen Cache; und
einen Gruppenadministrationsmechanismus zum Einrichten intermediärer Cachingpunkte, umfassend:
Mittel zum Zusammenfassen eines Satzes von zusammengehörigen Programmelementen in einer Gruppe; und
Mittel, die während der Verarbeitung einer Client- Anforderung aktiv werden, um in dem Cache zur späteren Wiederverwendung einen Gesamtausgang des Satzes von zusammengehörigen Programmelementen zu speichern, wobei ein einzelner Ausgang von mindestens einem Element aus dem Satz von zusammengehörigen Programmelementen in der Gruppe nicht in dem Cache gespeichert wird.

23. Ein Computersystem, umfassend:
einen Satz von Programmelementen;
einen Cache; und
einen Gruppenadministrationsmechanismus zum Einrichten intermediärer Cachingpunkte, umfassend:
Anzeigemittel, die es einem Systemadministrator ermöglichen, einen Satz von zusammengehörigen Programmelementen zu einer Gruppe zusammenzufassen; und
Mittel, die während der Verarbeitung von Client- Anforderungen aktiv werden, zum Speichern eines Gesamtausgangs des Satzes von zusammengehörigen Programmelementen im Cache, zur späteren Wiederverwendung.

24. Ein Computersystem, umfassend:
einen Satz von Programmelementen;
einen Cache; und
einen Gruppenadministrationsmechanismus zum Einrichten intermediärer Cachingpunkte, umfassend:
Mittel zum dynamischen Zusammenfassen eines Satzes von zusammengehörigen Programmelementen in einer Gruppe; und
Mittel, um in dem Cache einen Gesamtausgang des Satzes von zugehörigen Programmelementen zur späteren Wiederverwendung zu speichern.