-
HINTERGRUND
DER ERFINDUNG Technisches Gebiet
-
Die
vorliegende Erfindung betrifft ein Verfahren zum intermediären Cachen
in einem Client-Server-Softwaresystem, mit einer Vielzahl von Programmelementen
zum Umcodieren von Datenobjekten. Des Weiteren betrifft die Erfindung
Computerprogrammprodukte und ein Computersystem zur Durchführung eines
solchen Verfahrens.
-
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.
-
In
der WO 98/43177 wird ein System zum dynamischen Umcodieren von Daten
beschrieben, die zwischen einem Netzwerk-Server und einem Netzwerk-Client übertragen
werden. Die Umcodierung erfolgt mit Hilfe eines „transcoding server". Eine wesentliche
Komponente des „transcoding
server" ist ein „transcoder", der einen „parser" und eine Reihe von „transcode
service providers° umfasst,
wobei der "parser" einen passenden "transcode service
provider" für die Umcodierung
der empfangenen Daten auswählt.
Des Weiteren umfasst der hier beschriebene „transcoding server" ein „cache
memory" mit einem „cache
interface" zum Zwischenspeichern
des Ausgangs jeweils eines „transcode
service providers",
um bei einem späteren
Datentransfer bei entsprechender Anforderung ein bereits erzeugtes
Format nochmals verwenden zu können.
-
Gegenstand
der
US 5 918 013 A ist
ein Verfahren zum Abrufen und Umcodieren von Daten, die ein Client über einen
Proxy-Server von einem Remote Server angefordert hat. Hier wird
lediglich ganz allgemein auf die Möglichkeit hingewiesen, Informationen,
die regelmäßig abgerufen
werden, in einem Proxy-Cache abzuspeichern.
-
Mit
der vorliegenden Erfindung soll ein verbessertes Konzept für intermediäres Caching
beim Umcodieren von Datenobjekten in einem Client-Server-Softwaresystem
realisiert werden.
-
KURZE ZUSAMMENFASSUNG
DER ERFINDUNG
-
Das
erfindungsgemäße Verfahren
zum intermediären
Cachen umfasst folgende Schritte:
Zusammenfassen von in Beziehung
stehenden Programmelementen in einer Umcodierungsgruppe, wobei jede
Umcodierungsgruppe eine Reihe von administratordefinierten Umcodierern
umfasst und das Zusammenfassen mit Hilfe eines Gruppenadministrationsmanagers
erfolgt, indem die Programmelemente über eine Benutzerschnittstelle
des Gruppenadministrationsmanagers einer gegebenen oder neu erzeugten
Umcodierungsgruppe zugewiesen werden,
in Antwort auf eine Client-Anforderung,
Erzeugen eines modifizierten URL, der eine Reihe von Umcodierungsgruppen
kennzeichnet, die zur Erfüllung
der Client-Anforderung ausgeführt
werden müssen;
Ausführen der
Umcodierungsgruppen zur Erzeugung eines Ausgangsstroms; und
Cachen
eines Ausgangs mindestens eines Zwischen-Umcodierungsschritts, der
in der Ausführung sämtlicher
Programmelemente einer Umcodierungsgruppe besteht, zur späteren Wiederverwendung
des Ausgangs dieses Zwischen-Umcodierungsschritts.
-
Demnach
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 Lache
gespeichert. Dies 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.
-
Dieser
Caching-Mechanismus kann besonders vorteilhaft in der Domäne der Umcodierung
von Daten aus dem Web eingesetzt werden, indem ein Satz von zusammengehörigen Umcodierern
für Caching-Zwecke
in einer Gruppe zusammengefasst wwird. 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.
-
Eine
Gruppe von zusammengehörigen
Umcodierern wird 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
einer Variante des erfindungsgemäßen Verfahrens
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.
-
In
der obigen Beschreibung wurden einige Vorteile der vorliegenden
Erfindung angesprochen. Viele andere vorteilhafte Ergebnisse können erzielt werden,
wenn die beschriebene Erfindung, wie nachstehend beschrieben, modifiziert
wird.
-
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:
-
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;
-
2 ein
vereinfachtes Blockdiagramm eines Gruppenadministrationsmechanismus
der vorliegenden Erfindung;
-
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;
-
4a ein
Blockdiagramm einer Teilschicht einer WBI-Clientsitzung, in der
die vorliegende Erfindung implementiert werden kann;
-
4b ein
Blockdiagramm einer Teilschicht einer WBI-Transaktions-Sitzung,
die in Verbindung mit der Teilschicht der Clientsitzung aus 4a verwendet
wird;
-
5 ein
Blockdiagramm eines komplexen Softwaresystems, das eine Vielzahl
von Programmen veranschaulicht, die sequentiell und parallel arbeiten;
-
6,
wie eine Gruppe von Programmelementen zur Wiederverwendung zusammengefasst wird,
gemäß der vorliegenden
Erfindung; und
-
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 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 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. 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 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) String[]getDependenciesForGroup() – 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.
-
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 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 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 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 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 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 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 RequestHandle-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 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/group2/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 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 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 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 5–7 beschrieben.
-
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. 6 zeigt das Computersystem der 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 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 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.
-
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 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.