Herausforderungen des Web-Messaging-Service

Die Implementierung Web-Messaging-fähiger Anwendungen mit dem Bayeux-Protokoll bringt mehrere Herausforderungen mit sich, vor die alle COMET-Anwendungen mit langlebigen Verbindungen gestellt werden. Viele der Schwierigkeiten haben mit der Belastung zu tun, die die COMET-Kommunikation für die synchrone Natur verschiedener Bereiche der Internetinfrastruktur bedeutet. Der Web-Messaging-Service kann das Kanalframework nutzen und pro Anforderung mehr als nur einen Thread verwenden. Für viele andere Bereiche der Internetinfrastruktur ist dies jedoch schwierig.

Ein Bereich, der Schwierigkeiten mit dieser Threadskalierung haben könnte, ist ein Web-Server. Wenn IBM® HTTP Server for WebSphere® Application Server mit Web-Messaging-fähigen Anwendungen konfrontiert wird, muss IBM HTTP Server for WebSphere Application Server für die Verarbeitung zusätzlicher Anforderungen konfiguriert werden, denn die Zeit, die Anforderungen auf ein Ereignis warten, ist länger. IBM HTTP Server for WebSphere Application Server bindet eine wartende Anforderung an einen Thread und ist somit durch die maximale Anzahl für den Web-Server verfügbarer Threads beschränkt. In den meisten Web-Messaging-Installationen muss die Anzahl der Installationen von IBM HTTP Server for WebSphere Application Server für Anwendungen mit Web-Messaging erhöht werden.

Der Proxy-Server für WebSphere Application Server ist für die Konfrontation mit Web-Messaging-fähigen Anwendungen eine Alternative zu IBM HTTP Server for WebSphere Application Server. Der Proxy-Server für WebSphere Application Server bindet nicht jede ankommende Anforderung an einen Thread und ist somit in der Lage, eine größere Anzahl paralleler Clients zu bedienen als IBM HTTP Server for WebSphere Application Server. Beim Ersetzen von IBM HTTP Server for WebSphere Application Server durch den Proxy-Server für WebSphere Application Server kann es zu Problemen kommen. Im developerWorks-Artikel Know your proxy basics finden Sie weitere Informationen zum Einsatz des Proxy-Servers für WebSphere Application Server mit einer Web-Messaging-fähigen Anwendung. Für eine Web-Messaging-Lösung kann aber auch auf andere, hardwarebasierte Strategien zurückgegriffen werden. Sie müssen allerdings beachten, dass Sitzungsaffinität notwendig ist, damit in einer Clusterumgebung die Anforderungen zu demselben Server zurücktransportiert werden.

Begrenzung auf zwei Verbindungen

In den meisten Fällen wird der Client, der eine Verbindung zum Web-Messaging-Service herstellt, ein AJAX-Bayeux-Client in einem Webbrowser sein. Browser unterliegen hinsichtlich ihrer Verbindungen zu einem Server bestimmten Einschränkungen. Eine dieser Einschränkungen ist die Begrenzung auf zwei Verbindungen zu einem Server. Für den Aufbau einer Bayeux-Verbindung wird eine dieser Verbindungen genutzt, so dass noch eine freie Verbindung übrig bleibt. Eine Browserinstanz mit mehreren Registerkarten und Fenstern kann demzufolge nur eine Bayeux-Verbindung zu einem Server herstellen. Wenn ein ein zweites Browserfenster oder Registerkarten versuchen, eine langlebige Verbindung herzustellen, muss diese verweigert oder auf das konventionelle Polling zurückgesetzt werden. Diese Einschränkung müssen Sie verstehen und mit einplanen, wenn Sie eine Anwendung mit Web-Messaging entwickeln.

Außerdem müssen Sie darauf achten, ob während der Ausführung einer anderen zeitabhängigen Browserkommunikation eine Bayeux-Verbindung aufgebaut wird. Das Bayeux-Protokoll verwendet die zweite verfügbare Verbindung, um Informationen vom Server zu abonnieren, Subskriptionen zu beenden und Informationen auf dem Server zu veröffentlichen. Weitere Optionen, die eine Verbindung belegen, sind unter anderem: AJAX-XmlHttpRequest-Operationen, Grafik- oder HTML-Downloads und Dateiuploads. Wenn mehrere Operationen für einen Server über dieselbe Browserinstanz ausgeführt werden, kann Ihre Bayeux-Clientanwendung sehr langsam werden und beim Warten auf das Freiwerden einer Verbindung ein abweichendes Verhalten zeigen.



Nutzungsbedingungen | Feedback