-
Technisches Gebiet
-
Die Erfindung betrifft Web-Anwendungen. Insbesondere betrifft die Erfindung eine Vorrichtung, ein Verfahren und ein Computerprogramm zum Verwalten asynchroner Anforderungen von einer Web-Anwendung.
-
Hintergrund der Erfindung
-
Durch Webclients ausgeführte Web-Anwendungen verwenden üblicherweise asynchrone Anforderungen, um von Webservern auf Ressourcen zuzugreifen. Asynchrone Anforderungen werden so verwendet, dass Web-Anwendungen im Hintergrund auf Ressourcen zugreifen können, ohne die bestehende Webseite zu beeinträchtigen.
-
Webbrowser begrenzen die Anzahl gleichzeitig ablaufender asynchroner Anforderungen, die durch eine Web-Anwendung ausgeführt werden können. In der Spezifikation der Hypertext-Transfer-Protocol-(HTTP-)Version 1.1 ist die Grenze auf zwei gleichzeitig ablaufende Anforderungen festgelegt. Ein Beispiel einer zum Realisieren asynchroner Anforderungen verwendeten Technologie ist Ajax (asynchronous JavaScript + Extensible Markup Language). Ajax-Anforderungen von einem Client können Daten asynchron im Hintergrund von einem Server abrufen, ohne eine bestehende Webseite zu beeinträchtigen.
-
Die Grenze hat bei aus Steuerelementen (ein Steuerelement (widget) ist ein Stück dynamischer Inhalt, das in eine Webseite gesetzt werden kann) erstellten Web-Anwendungen erhebliche Leistungseinbußen und Engpässe zur Folge. Steuerelemente können die durch die Browser bereitgestellte native Schnittstelle (zum Beispiel ein XMLHttpRequest-Objekt in JavaScript) verwenden, um über asynchrone Anforderungen Inhalt abzurufen. Die ein Steuerelement einbettende Web-Anwendung hat keine direkte Kontrolle über die durch das Steuerelement ausgeführte Logik und insbesondere darüber, ob das Steuerelement eine asynchrone Anforderung gestartet hat.
-
Weitere Beispiele für durch eine Grenze verursachte Leistungseinbußen sind: eine lange Reaktionszeit für eine Anforderung, die ein Browser in eine Warteschlange einreiht; und ein Überlauf der Anzahl von Anforderungen, wenn eine Webseite geladen wird. Die Grenze hat außerdem eine Unfähigkeit, für die Anforderungen eine Prioritätsstufe festzusetzen, zur Folge. Überdies sind Optimierungen nicht möglich, weil zwei oder mehr (ungefähr) gleichzeitig durch verschiedene Steuerelemente (oder verschiedene Instanzen ein und desselben Steuerelements) gesendete Anforderungen an dieselbe Ressource genauso wie unabhängige Anforderungen behandelt werden, wenn es möglich wäre, die Ressource nur einmal abzurufen.
-
Ein weiteres Beispiel einer durch die Grenze verursachten Leistungsminderung ist die für die Web-Anwendung bestehende Schwierigkeit, die Webbrowser-Warteschlange unter Kontrolle zu haben. Die Webbrowser-Anforderungswarteschlange ist geordnet, was bedeutet, dass eine lange Reaktionszeit bei einer augenblicklich durch den Webbrowser verarbeitet werdenden Anforderung dazu führen kann, dass der Webbrowser die nachfolgenden Anforderungen in die Warteschlange einreiht, bis die Antwort auf die augenblicklich verarbeitet werdende Anforderung empfangen wird, auch wenn die nachfolgenden Anforderungen möglicherweise viel schneller als die augenblicklich verarbeitet werdende Anforderung antworten könnten.
-
Die US-Patentanmeldung mit der Veröffentlichungsnummer
US 2009/0144707 A1 offenbart ein Verfahren, System und Computerprogramm-Produkt zum wirkungsvollen Erfüllen von Java-Serverseiten-Anforderungen dynamischer Web-Inhalte. Ein Hilfsprogramm zur asynchronen Verarbeitung definiert eine Anzahl angepasster Klassen vor, um die asynchrone Verarbeitung von Anforderungen zu ermöglichen.
-
Deshalb besteht in diesem Fachgebiet ein Bedarf, das obengenannte Problem zu lösen.
-
Kurzbeschreibung der Erfindung
-
In einer ersten Sichtweise stellt die vorliegende Erfindung eine Client-Vorrichtung zur Verwendung mit einem Datenverarbeitungssystem bereit, welches Datenverarbeitungssystem einen Client und einen Server umfasst, wobei die Vorrichtung Folgendes umfasst: eine Empfängerkomponente zum Empfangen eines Aufrufs von einer Client-Anwendung an ein erstes Verfahren eines Objekts, wobei das erste Verfahren eine erste Anforderung an den Server umfasst und wobei die erste Anforderung eine erste Vielzahl von Attributen umfasst; eine auf das Empfangen des Aufrufs durch die Empfängerkomponente ansprechende Abfangkomponente zum Verpacken des Objekts, um einem zweiten Verfahren des verpackten Objekts einen verpackten Aufruf bereitzustellen, wobei das zweite Verfahren eine zweite Anforderung an den Server umfasst; eine auf das Verpacken des Objekts durch die Abfangkomponente ansprechende Client-Codierer-Komponente zum Umwandeln des verpackten Aufrufs in eine Nachricht, wobei die Nachricht die erste Vielzahl von Attributen umfasst; eine auf das Umwandeln der Anforderung durch die Client-Codierer-Komponente ansprechende, zum Einrichten eines Kanals zum Server dienende Client-Kanalverwalter-Komponente; und eine auf das Einrichten des Kanals durch den Client-Kanalverwalter ansprechende Senderkomponente zum Senden der Nachricht auf dem Kanal.
-
Vorzugsweise stellt die vorliegende Erfindung eine Client-Vorrichtung bereit, wobei die Client-Vorrichtung außerdem umfasst: die außerdem zum Empfangen einer Rückmeldung auf dem Kanal dienende Empfängerkomponente, wobei die Rückmeldung eine zweite Vielzahl von Attributen umfasst; eine auf das Empfangen der Rückmeldung durch die Empfängerkomponente ansprechende Rückmeldungsdecodierer-Komponente zum Decodieren der Rückmeldung, um eine Antwort bereitzustellen, wobei die Antwort die zweite Vielzahl von Attributen umfasst; die auf das Decodieren der Rückmeldung durch die Rückmeldungsdecodierer-Komponente ansprechende, außerdem zum Aufrufen einer Antwortenbehandlungsroutine dienende Abfangkomponente; und die auf das Aufrufen der Antwortenbehandlungsroutine ansprechende, außerdem zum Senden der Antwort an die Client-Anwendung dienende Senderkomponente.
-
Vorzugsweise stellt die vorliegende Erfindung eine Client-Vorrichtung bereit, wobei die Client-Vorrichtung in der Client-Anwendung betreibbar ist. Vorzugsweise stellt die vorliegende Erfindung eine Client-Vorrichtung bereit, wobei die Client-Vorrichtung in einem Webbrowser betreibbar ist.
-
In einer zweiten Sichtweise stellt die vorliegende Erfindung eine Server-Vorrichtung zur Verwendung mit einem Datenverarbeitungssystem bereit, welches Datenverarbeitungssystem einen Client und einen Server umfasst, wobei die Vorrichtung Folgendes umfasst: eine Server-Kanalverwalter-Komponente zum Empfangen einer Nachricht auf einem Kanal von einem Client, wobei die Nachricht eine erste Vielzahl von Attributen umfasst; eine auf das Empfangen der Nachricht durch die Server-Kanalverwalter-Komponente ansprechende Server-Decodierer-Komponente zum Decodieren der Nachricht, um eine Anforderung bereitzustellen, wobei die Anforderung die erste Vielzahl von Attributen umfasst; und eine auf das Bereitstellen der Anforderung zum Abrufen einer Antwort durch die Server-Decodierer-Komponente ansprechende Antwortenabrufer-Komponente zum Senden der Anforderung an eine Ressource.
-
Vorzugsweise stellt die vorliegende Erfindung eine Server-Vorrichtung bereit, wobei die Server-Vorrichtung außerdem umfasst: die außerdem zum Empfangen einer Antwort von der Ressource dienende Antwortenabrufer-Komponente, wobei die Antwort eine zweite Vielzahl von Attributen umfasst; eine auf das Empfangen der Antwort durch die Antwortenabrufer-Komponente ansprechende Antwortencodierer-Komponente zum Codieren der Antwort, um eine Rückmeldung bereitzustellen, wobei die Rückmeldung die zweite Vielzahl von Attributen umfasst; und die auf das Bereitstellen einer Rückmeldung durch die Antwortencodierer-Komponente ansprechende, außerdem zum Senden der Rückmeldung auf dem Kanal dienende Server-Kanalverwalter-Komponente.
-
In einer dritten Sichtweise stellt die vorliegende Erfindung ein Client-Verfahren zur Verwendung mit einem Datenverarbeitungssystem bereit, welches Datenverarbeitungssystem einen Client und einen Server umfasst, wobei das Verfahren die folgenden Schritte umfasst: das Empfangen eines Aufrufs von einer Client-Anwendung an ein erstes Verfahren eines ersten Objekts, wobei das erste Verfahren eine erste Anforderung an den Server umfasst und wobei die erste Anforderung eine erste Vielzahl von Attributen umfasst; auf das Empfangen des Aufrufs hin das Verpacken des Objekts, um einem zweiten Verfahren des verpackten Objekts einen verpackten Aufruf bereitzustellen, wobei das zweite Verfahren eine zweite Anforderung an den Server umfasst; auf das Verpacken des Objekts hin das Umwandeln des verpackten Aufrufs in eine Nachricht, wobei die Nachricht die erste Vielzahl von Attributen umfasst; auf das Umwandeln der Anforderung hin das Einrichten eines Kanals zum Server; und auf das Einrichten des Kanals hin das Senden der Nachricht auf dem Kanal.
-
Vorzugsweise stellt die vorliegende Erfindung ein Client-Verfahren bereit, wobei das Client-Verfahren außerdem die folgenden Schritte umfasst: das Empfangen einer Rückmeldung auf dem Kanal, wobei die Rückmeldung eine zweite Vielzahl von Attributen umfasst; auf das Empfangen der Rückmeldung hin das Decodieren der Rückmeldung, um eine Antwort bereitzustellen, wobei die Antwort die zweite Vielzahl von Attributen umfasst; auf das Decodieren der Rückmeldung hin das Aufrufen einer Antwortenbehandlungsroutine; und auf das Aufrufen der Antwortenbehandlungsroutine hin das Senden der Antwort an die Client-Anwendung.
-
Vorzugsweise stellt die vorliegende Erfindung ein Client-Verfahren bereit, wobei das Client-Verfahren in der Client-Anwendung ausführbar ist. Vorzugsweise stellt die vorliegende Erfindung ein Client-Verfahren bereit, wobei das Client-Verfahren in einem Webbrowser ausführbar ist.
-
In einer vierten Sichtweise stellt die vorliegende Erfindung ein Server-Verfahren zur Verwendung mit einem Datenverarbeitungssystem bereit, welches Datenverarbeitungssystem einen Client und einen Server umfasst, wobei das Verfahren die folgenden Schritte umfasst: das Empfangen einer Nachricht auf einem Kanal von einem Client, wobei die Nachricht eine erste Vielzahl von Attributen umfasst; auf das Empfangen der Nachricht hin das Decodieren der Nachricht, um eine Anforderung bereitzustellen, wobei die Anforderung die erste Vielzahl von Attributen umfasst; und auf das Bereitstellen der Anforderung zum Abrufen einer Antwort hin das Senden der Anforderung an eine Ressource.
-
Vorzugsweise stellt die vorliegende Erfindung ein Server-Verfahren bereit, wobei das Verfahren außerdem die folgenden Schritte umfasst: das Empfangen einer Antwort von der Ressource, wobei die Antwort eine zweite Vielzahl von Attributen umfasst; auf das Empfangen der Antwort hin das Codieren der Antwort, um eine Rückmeldung bereitzustellen, wobei die Rückmeldung die zweite Vielzahl von Attributen umfasst; und auf das Bereitstellen einer Rückmeldung hin das Senden der Rückmeldung auf dem Kanal.
-
In einer weiteren Sichtweise stellt die vorliegende Erfindung ein Systemprogramm bereit, das auf einem computerlesbaren Medium gespeichert ist und in den Teile von Software-Code enthaltenden internen Speicher einer digitalen Rechenanlage geladen werden kann, wenn das Programm, zum Ausführen der Schritte der Erfindung, auf einem Computer ausgeführt wird.
-
Vorteilhafterweise stellt die vorliegende Erfindung eine merkliche Verbesserung der Leistungsniveaus einer aus Fremd-Erweiterungen/-Steuerelementen, die ihre eigene clientseitige Logik wie Steuerelemente einbetten, bestehenden Web-Anwendung bereit.
-
Vorteilhafterweise gestattet die vorliegende Erfindung, alle durch die verschiedenen Komponenten/Steuerelemente auf der Seite erzeugten asynchronen Anforderungen über einen durch eine Web-Anwendung aufrechterhaltenen verwalteten Kanal zwischen einem Client und einem Server auf eine transparente Weise an Aufrufer weiterzuleiten. Diese Erfindung beinhaltet die clientseitigen und serverseitigen Mechanismen zum Erzeugen, Aufrechterhalten, Verwalten und Benutzen eines solchen Kanals zwischen dem Client und dem Server, um die asynchronen Anforderungen auf eine transparente Weise zu leiten. Der Kanal kann entweder permanent über eine „Comet”-Verbindung oder virtuell über eine Reihe aufeinanderfolgender kontrollierter Ajax-Anforderungen aufrechterhalten werden.
-
Ebenso vorteilhafterweise ist dieser Mechanismus für jede eine asynchrone Anforderung erzeugende Komponente verborgen, so dass die gleichen Ergebnisse geliefert werden, wie wenn dem Stand der Technik entsprechende native JavaScript-Objekte zum Senden der Ajax-Anforderungen verwendet werden. Deshalb sind keine Änderungen am Code der Web-Anwendung oder an irgendwelchen darin enthaltenen Fremd-Steuerelementen erforderlich. Eine Web-Anwendung kann die Webbrowser-Warteschlange umgehen und Anforderungen unmittelbar über einen permanenten Kanal an einen Webserver senden.
-
Vorteilhafterweise ist der Mechanismus auf jede Client-Anwendung, die Fremd-Skriptcode (zum Beispiel JavaScript-Code) enthält, und nicht nur auf „grafische” Steuerelemente anwendbar. Zum Beispiel auf ein Steuerelement, das Maße erfasst und die Daten an einen entfernten Server sendet.
-
Die Erfindung lässt sich auf jede Anwendung verallgemeinern, die eine Web-Komponente enthält, welche in der Lage ist, Logik über Skriptcode auszuführen, um asynchrone Anforderungen zu starten.
-
Kurzbeschreibung der Zeichnungen
-
Nun wird die vorliegende Erfindung, nur beispielhaft, unter Bezugnahme auf bevorzugte Ausführungsformen beschrieben, wie sie die folgenden Figuren veranschaulichen:
-
1 ist ein Blockschaltbild, das ein Datenverarbeitungssystem gemäß dem Stand der Technik darstellt, in welchem eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann;
-
2 ist ein Blockschaltbild, das eine dem Stand der Technik entsprechende Web-Anwendung darstellt;
-
3 ist ein grober beispielhafter schematischer Ablaufplan, welcher zwecks Interaktion mit einer Server-Vorrichtung einer serverseitigen Web-Anwendung ausgeführte Arbeitsverfahrensschritte einer Client-Vorrichtung gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung darstellt; und
-
4 ist ein Blockschaltbild, das eine Client-Vorrichtung und eine Server-Vorrichtung darstellt, in welchen eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann.
-
Ausführliche Beschreibung der Erfindung
-
1 ist ein Blockschaltbild, das ein Datenverarbeitungssystem 100 gemäß dem Stand der Technik darstellt, in welchem eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann. Ein Beispiel eines Datenverarbeitungssystems 100 ist das Internet. Ein Webbrowser 130 kann durch einen Benutzer 136 auf einem Datenverarbeitungssystem 100, das eine Arbeitsplatzstation 120 sowie Server 150 und 152 umfasst, betrieben werden. Die Arbeitsplatzstation 120 und die Server können über ein Netzwerk 114, welches drahtgebundene Netzwerke 110 umfassen kann, verbunden werden.
-
Üblicherweise kann auch ein Namenserver 152 mit dem Netzwerk 114 verbunden werden. Ein Namenserver 152 übersetzt einen Uniform Resource Locator (URL) in eine Internet-Protocol-(IP-)Adresse. Der Benutzer 136 greift auf das Internet zu, indem er mit dem auf einer Arbeitsplatzstation 120 betreibbaren Webbrowser 130 interagiert. Auch eine clientseitige Web-Anwendung 140 kann auf der Arbeitsplatzstation 120 unter Datenaustausch mit einer auf dem Server 150 ausführbaren serverseitigen Anwendung 170 ausgeführt werden. Die clientseitige Web-Anwendung 140 ist für den Benutzer 136 durch den Webbrowser 130 sichtbar. Die clientseitige Web-Anwendung 140 interagiert auch mit dem Webbrowser 130. Der Webbrowser 130 tauscht mit einem auf dem Server 150 betreibbaren Webserver 160 Daten aus. Der Webserver 160 interagiert mit der serverseitigen Web-Anwendung 170. Folglich interagiert die clientseitige Web-Anwendung 140 mit der serverseitigen Web-Anwendung 170.
-
2 ist ein Blockschaltbild 200, das eine dem Stand der Technik entsprechende Web-Anwendung darstellt. Eine clientseitige Web-Anwendung 140, 240 umfasst Anwendungscode 242 und Fremd-Steuerelementecode 244. Ein Steuerelement 244 ist ein Element einer grafischen Benutzeroberfläche, das einen Interaktionspunkt für einen Benutzer 136 bereitstellt.
-
Der Anwendungscode 242 und der Fremd-Steuerelementecode 244 enthalten JavaScript-(JS-)Code. Zur Interaktion mit der serverseitigen Web-Anwendung 170, 270 nutzt der Code 242, 244 die Dokumentobjektmodell-(DOM-)Anwendungsprogrammierschnittstelle (API) 246 mit einem Verfahrensaufruf an ein XMLHttpRequest-(XHR-)Objekt (zum Beispiel ein „send()”- oder ein „open()”-Verfahren), um Anforderungen an einen Webserver 160, 260 zu senden. Ein „send()”-Aufruf vom Code 242, 244 ist ein Befehl, eine Anforderung 236 an den Webserver 160, 260 zu senden. Wenn mehr als eine bestimmte Anzahl von augenblicklich durch den Webbrowser 130, 230 verarbeitet werdenden Anforderungen 236 vorliegen, reiht der Webbrowser 130, 230 eine neue Anforderung 236 in eine geordnete Warteschlange 235 ein. Der Webbrowser 130, 230 sendet die Anforderung 236, sobald er eine Antwort 238 auf eine frühere Anforderung 236 vom Webserver 160, 260 zurückempfängt. Die Beschränkungen der geordneten Warteschlange 235 erzeugen Engpässe und Leistungsprobleme. Die Reihenfolge in der Warteschlange 235 beruht auf dem Windhundverfahren. Web-Anwendungen 140, 240 haben keinerlei Kontrolle über die Warteschlange 235 und erhalten auch keine Informationen über die Inhalte der Warteschlange 235. Sobald eine Antwort 238 empfangen wird, wird sie über das ursprünglich zum Senden der Anforderung verwendete XMLHttpRequest-Objekt an den aufrufenden Code 242, 244 zurückgeleitet.
-
Die Transaktion zwischen dem Browser 130, 230 und dem Webserver 160, 260 wird durch das XHR-Objekt verwaltet. Das XHR-Objekt ist das durch den Webbrowser 130, 260 bereitgestellte native Objekt, das dazu verwendet wird, asynchrone JavaScript- und XML-(Ajax-)Anforderungen in JavaScript an den Server zu senden.
-
3, die zusammen mit 4 betrachtet werden sollte, ist ein grober beispielhafter schematischer Ablaufplan 300, welcher zwecks Interaktion mit einer Server-Vorrichtung 452 einer serverseitigen Web-Anwendung 170, 470 ausgeführte Arbeitsverfahrensschritte einer Client-Vorrichtung 450 gemäß einer bevorzugten Ausführungsform der vorliegenden Erfindung darstellt. 4 zeigt ein Blockschaltbild 400, das eine Client-Vorrichtung 450 und eine Server-Vorrichtung 450, Web-Anwendungen 440, 470 darstellt, in welchen eine bevorzugte Ausführungsform der vorliegenden Erfindung realisiert werden kann.
-
3 stellt einen Logik-Ablaufplan dar. Als solche sind die dargestellte Reihenfolge und die benannten Schritte für eine Ausführungsform des vorgestellten Verfahrens bezeichnend. Weitere Schritte und Verfahren können erdacht werden, welche in Funktion, Logik oder Wirkung einem oder mehreren Schritten oder Teilen von Schritten des veranschaulichten Verfahrens gleichwertig sind. Außerdem dienen das verwendete Format und die verwendeten Symbole dazu, die logischen Schritte des Verfahrens zu erläutern, und sind sie nicht als den Umfang des Verfahrens begrenzend zu verstehen.
-
Das Verfahren beginnt mit Schritt 301. Eine clientseitige Web-Anwendung 140, 440 umfasst Anwendungscode 442 und Fremd-Steuerelementecode 444. In Schritt 305 empfängt eine Abfangkomponente 455 der Client-Vorrichtung 450 vom Code 442, 444 einen Aufruf an ein XHR-Objekt, eine Anforderung an eine serverseitige Web-Anwendung 170, 470 zu senden. Der XHR-Objekt-Aufruf umfasst Attribute (zum Beispiel einen URL, Vorsätze und Inhalt).
-
In Schritt 305 erzeugt eine Abfangkomponente 455 vor einem ersten Aufruf an das native XHR-Objekt durch den Code 442, 444 eine Verpackung um das native XHR-Objekt. Das verpackte XHR-Objekt verfügt über die gleichen Verfahren wie das native XHR-Objekt. Das Verpacken des nativen XHR-Objekts gestattet der Abfangkomponente 455, alle Aufrufe an eines der Verfahren des nativen XHR-Objekts abzufangen. Alle Verfahren des nativen XHR-Objekts werden verpackt, um die durch den aufrufenden Code 442, 444 festgesetzten Anforderungsattribute aufzuzeichnen. Der aufrufende Code 442, 444 ruft das verpackte XHR-Objekt auf, wie wenn das native XHR-Objekt aufgerufen wird. Wenn der Code 442, 444 eines der Verfahren des nativen XHR-Objekts aufruft, fängt die Abfangkomponente 455 den Aufruf ab und ruft stattdessen eines der Verfahren des verpackten XHR-Objekts auf. Der Code 442, 444 hat keine Kenntnis von dem Mechanismus, den die Client-Vorrichtung 450 und die Server-Vorrichtung 452 verwenden, um die Anforderung weiterzuleiten.
-
In Schritt 310 empfängt die Abfangkomponente 455 der Client-Vorrichtung 450 vom Code 442, 444 einen Aufruf an das native XHR-Objekt, eine Anforderung an eine serverseitige Web-Anwendung 170, 470 zu senden. Der XHR-Objekt-Aufruf umfasst Attribute (zum Beispiel einen URL, Vorsätze und Inhalt).
-
In Schritt 315 ruft die Abfangkomponente 455 eine Client-Anforderungscodierer-Komponente 430 auf, wenn der Code 442, 444 eines der Verfahren des nativen XHR-Objekts aufruft. Der Ausdruck „eine Anforderung” bezieht sich auf einen Aufruf an eines der XHR-Verfahren, ein HTTP an einen Webserver 160 zu senden und eine Antwort des Webservers 160 direkt zurück in den aufrufenden Anwendungscode zu laden.
-
In Schritt 320 codiert die Client-Anforderungscodierer-Komponente 430 die Anforderungsattribute in einem bestimmten Format, so dass sie über einen permanenten Kanal oder einen halbpermanenten Kanal 445 gesendet werden können. Durch das Codieren der Anforderungsattribute wird eine Nachricht in dem bestimmten Format erzeugt, so dass die Nachricht über den Kanal 445 gesendet werden kann. Die Nachricht umfasst sämtliche Attribute der Anforderung.
-
In Schritt 325 richtet eine Client-Kanalverwalter-Komponente 440 einen Kanal 445 zu einer Server-Kanalverwalter-Komponente 465 in einem Server ein. Der Kanal 445 kann auf bestehenden Protokollen wie Bayeux beruhen. Bayeux ist ein Protokoll zum Übertragen asynchroner Nachrichten vor allem über HTTP mit kurzer Wartezeit zwischen einem Webserver. Ein Beispiel einer Umsetzung des Bayeux-Protokolls ist CometD. Der Kanal 445 ist eine einzelne Verbindung, über welche Informationen mehrerer Anforderungen oder Antworten in einem bestimmten Format ausgetauscht werden. In einer bevorzugten Ausführungsform wird der Kanal beim ersten Mal, dass eine Anforderung gesendet wird, erzeugt. Für alle nachfolgenden Anforderungen wird derselbe Kanal wiederverwendet.
-
In Schritt 330 empfängt die Server-Kanalverwalter-Komponente 465 die Nachricht. In Schritt 335 decodiert eine Server-Anforderungsdecodierer-Komponente 460 die Anforderungsattribute in der Nachricht, die über den Kanal 445 gesendet wurden. In Schritt 340 sendet eine Antwortenabrufer-Komponente 472 auf Grundlage der decodierten Attribute echte HTTP-Anforderungen entweder an eine lokale Ressource 474 der serverseitigen Web-Anwendung 470 oder an eine externe Quelle 480. In Schritt 345 empfängt die Antwortenabrufer-Komponente 472 von der lokalen Ressource 474 oder der externen Ressource 480 eine Antwort zurück. In Schritt 345 codiert die Antwortencodierer-Komponente 462 die Antwortattribute in einem bestimmten Format in eine Rückmeldung. In Schritt 355 sendet die Server-Kanalverwalter-Komponente 465 die Rückmeldung über den Kanal 445 an die Client-Kanalverwalter-Komponente 440. Als „Ressource” wird alles bezeichnet, was mittels einer HTTP-Anforderung abgerufen werden kann. Zum Beispiel kann eine Ressource eine statische Ressource oder ein Aufruf an eine Representational-State-Transfer-(REST-)API sein.
-
In Schritt 360 empfängt die Client-Kanalverwalter-Komponente 440 über den Kanal 445 die Rückmeldung, und in Schritt 365 ruft sie eine Rückmeldungsdecodierer-Komponente 435 auf. In Schritt 370 decodiert eine Antwortendecodierer-Komponente 435 die Rückmeldung in eine Antwort. In Schritt 380 ruft die Abfangkomponente 455 eine Antwortenbehandlungsroutine im aufrufenden Code 442, 444 auf. Die Antwortenbehandlungsroutine befindet sich im verpackten XHR-Objekt. Die Antwortenbehandlungsroutine stellt dem aufrufenden Code 442, 444 die Antwort genauso bereit, wie es das native XHR-Objekt gemacht hätte, so dass das Verfahren für den aufrufenden Code 442, 444 transparent ist.
-
Die Client-Anforderungscodierer-Komponente 430 setzt einen eindeutigen Nachrichten-Identifikationscode (ID) für die über den Kanal 445 gesendete Nachricht fest. Die Server-Vorrichtung 452 behält die Nachrichten-ID im Auge und setzt eine Zuordnungs-Rückmeldungs-ID in der Rückmeldung fest, welche der Nachrichtenanforderungs-ID entspricht, so dass die Client-Vorrichtung 450 zuordnen kann, welche Rückmeldung zu welcher über den Kanal 445 gesendeten Nachricht gehört.
-
Das Verfahren endet mit Schritt 399.
-
In einer bevorzugten Ausführungsform verpackt die Abfangkomponente 455 das native XHR-Objekt durch dynamisches Außerkraftsetzen der Eigenschaften/Verfahren dieses Objekts beim Laden der Seite.
-
Die Verfahren und Vorrichtungen eignen sich auch für Skriptsprache-(zum Beispiel JS-)Bibliotheken, welche die Weise, auf welche die Ajax-Anforderungen gesendet werden, abstrahieren, weil das XHR-Objekt immer als eine Grundlage zum Senden asynchroner Anforderungen verwendet wird.
-
Bayeux-Verfahren konzentrieren sich auf das Konzept anwendungsspezifischer Daten, die durch das Protokoll zwischen einem Browser und einem Server gesendet werden, wohingegen die Verfahren und Vorrichtungen einer vorliegenden Erfindung sich auf allgemeine asynchrone Anforderungen beziehen. Clientseitiger Code (zum Beispiel Client-Anwendungen, Steuerelemente 442, 444) nutzt ausdrücklich die Bayeux-Protokolle, wohingegen die vorliegende Erfindung eine transparente Weise, die Anforderung von Code 442, 444 zu kanalisieren, beschreibt. Jedoch kann das Bayeux-Protokoll für eine Realisierung der zugrundeliegenden Struktur dieses Patents verwendet werden.
-
In der bevorzugten Ausführungsform ist die Client-Vorrichtung 450 als JavaScript-Code in der Client-Web-Anwendung 440 realisiert. In einer alternativen Ausführungsform ist die Client-Vorrichtung 450 als Zusatzcode für den Webbrowser 130, 230 realisiert. In einer alternativen Ausführungsform ist die Client-Vorrichtung 450 als eine Abänderung am Kern-Quellcode des Webbrowsers 130, 230 realisiert.
-
In einer alternativen Ausführungsform wird das Verfahren auf das Abfangen weiterer nativer Objekte, welche Client-Anforderungen an einen Server starten, angewendet. Beispiele aus JavaScript sind: „script” zum Laden einer Skriptdatei; „iframe” zum Laden einer Seite; „img” zum Laden eines Bilds; und „link” zum Laden einer Stilvorlage von einem entfernten Server). Wie dem Fachmann klar ist, finden die Vorrichtungen und Verfahren auch bei weiteren Skriptsprachen für Client-Server-Interaktionen Anwendung, obwohl JavaScript zur Veranschaulichung einer bevorzugten Ausführungsform der Erfindung verwendet wurde.
-
Wie dem Fachmann klar ist, kann das Verfahren der bevorzugten Ausführungsformen der vorliegenden Erfindung ganz oder teilweise angemessen und zweckdienlich in einer Logikvorrichtung oder einer Vielzahl von Logikvorrichtungen verkörpert sein, welche zum Ausführen der Schritte des Verfahrens angeordnete Verknüpfungsglieder umfasst, und können solche Verknüpfungsglieder Hardware-Komponenten, Firmware-Komponenten oder eine Kombination daraus umfassen.
-
Man wird erkennen, dass das oben beschriebene Verfahren und die oben beschriebene Anordnung auch ganz oder teilweise in auf einem oder mehreren Prozessoren (in den Figuren nicht dargestellt) laufender Software angemessen ausgeführt werden können und dass die Software in Form eines oder mehrerer auf einem geeigneten Datenträger (ebenfalls in den Figuren nicht dargestellt) wie einer magnetischen oder optischen Speichereinheit oder dergleichen befindlicher Computerprogramm-Elemente bereitgestellt werden kann.
-
Um jeden Zweifel zu vermeiden, ist zu beachten, dass der Ausdruck „umfasst”, wie er hierin überall in der Beschreibung und in den Ansprüchen verwendet wird, nicht „besteht nur aus” bedeutet. Um jeden Zweifel zu vermeiden, ist ferner zu beachten, dass der Ausdruck „Kopieren einer Stelle an eine andere”, wie er hierin überall in der Beschreibung und in den Ansprüchen verwendet wird, „Kopieren des Dateninhalts einer Stelle an die andere Stelle” bedeutet.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 2009/0144707 A1 [0007]
