Remote Request Dispatcher

Remote Request Dispatcher (RRD) ist eine Plug-in-Erweiterung des Web-Containers für Anwendungsframeworks, Servlets und JavaServer Pages, mit der externe Inhalte (d. h. Inhalte, die nicht aus der aktuellen Java™ Virtual Machine stammen) für die Ressource in die Antwort einzuschließen, die an den Client gesendet wird.

Remote Request Dispatcher ist eine erweiterbare Infrastruktur für andere Komponenten und Zusatzprodukte, die das Hinzufügen angepasster Erweiterungen wie Generatoren oder Handler zur RRD-Erweiterung ermöglicht. Die RRD-Erweiterung erweitert die Standard-Java-EE-Implementierung (Java Platform, Enterprise Edition) von javax.servlet.RequestDispatcher so, dass über Web-Services ferne Ressourcen für die Kommunikation zwischen Maschinen in einer Stammgruppe von WebSphere Application Server Network Deployment (ND) ermittelt werden können. Die RRD-Erweiterung meldet alle Fehler, die im fernen Server auftreten, an den Ursprungsserver zurück. Sie kann auch SSL für eine sichere Kommunikation und die Weitergabe von WS-Security-Sicherheitskontexten zwischen Servern verwenden. Weitere Informationen finden Sie im Artikel über die Datei "rrdSecurity.props".

Die RRD-Portletunterstützung überträgt das RRD-Konzept in Portlets und erweitert den Portlet-Container so, dass Portlets außerhalb der aktuellen JVM-Ressource aufgerufen werden können.

Wenn Sie die RRD-Erweiterung verwenden, können Sie die Anforderungslast auf mehrere Maschinen und JVMs verteilen, indem Sie ferne Server in die Zelle einschließen. Wenn die RRD-Ressource viel Speicher oder Prozessorleistung belegt, wird die aufrufende Ressource weniger beeinflusst als ein Standard-RequestDispatcher, der in derselben JVM ausgeführt wird. RRD löst dieses Problem durch Übergabe von Ressourcen an eine andere JVM.

Funktionalität

  • Anforderungen auf dem fernen Server werden als Include-Anforderungen behandelt. Filter und Anforderungslistener werden wie beim Zuteilungstyp INCLUDE gestartet.
  • Serialisierbare Anforderungsattribute und Abfrageparameter werden an einen fernen Server gesendet.
  • Der Sicherheitskontext wird über LTPA-Token an den fernen Server gesendet.
  • Servlet-Parameter und Ausgabedatenstrom

    Anforderungsparameter werden an den fernen Server übergeben.

  • Antwortheader, die von fernen Include-Ressourcen gesetzt werden, werden ähnlich wie Include-Ressourcen auf einem lokalen Server ignoriert. Interne Header, wie z. B. Set-Cookie, können noch immer gesetzt werden und werden zurück übergeben.
  • Alle ursprünglichen Anforderungsheader werden an den fernen Server übergeben.
    • Gleicht dem Plug-in für WebSphere Application Server.
    • Methodenaufrufe geben den Status zurück, als befänden sie sich auf dem lokalen Server. Die Methode "getServer" gibt beispielsweise den Namen des lokalen Servers zurück, und "isSecure" gibt zurück, ob die Anforderung an den "lokalen" Server gesichert wurde.
  • Cookies und Sitzungen
    • Cookies werden als Bestandteil der Header an den fernen Server übergeben.
    • Sitzungen in lokalen und fernen Servern verwenden dasselbe Cookie bzw. dieselbe Sitzungs-ID für einen bestimmten Client (gleicht Includes in demselben Server). Wenn eine Sitzung auf einem fernen Server vorhanden ist, enthält das Sitzungs-Cookie die Informationen für beide Server, um die Affinität zum fernen Server aufrechtzuerhalten.
  • Ausnahmen
    • Tritt im fernen Server eine Ausnahme ein, gibt der Server einen RRD-spezifischen Web-Service-Fehler zurück, der die ursprüngliche Ausnahme enthält, die von der Anwendung erstellt wurde.
    • Versuchen Sie, die ursprüngliche Ausnahmebedingung auf dem lokalen Server erneut zu erstellen, wenn die Ausnahmebedingungsklasse auf beiden Servern vorhanden ist. Wenn die ursprüngliche Ausnahme nicht reproduziert werden kann, wird eine RRD-spezifische Ausnahme des Typs "ServletException" erstellt und stattdessen verwendet.
    • Die Ausnahmebedingung wird vom lokalen Server zur Fehlerbehandlung erneut erstellt.
  • Dynamischer Cache

    Wenn der dynamische Cache aktiviert ist, wird das Caching auf dem lokalen und dem fernen System ausgeführt.

  • Sicherheit

    Sie können RRD-Nachrichten zwischen Anwendungsservern mit SSL verschlüsseln. SSL ist standardmäßig aktiviert, aber Sie müssen die Sicherheitskontextanforderungen auch über RRD übergeben, um sicherzustellen, dass der Sicherheitsstatus in der fernen Maschine verfügbar ist. RRD verwendet WS-Security, um diese Informationen zu übergeben, aber diese Weitergabe von Sicherheitskontexten ist standardmäßig inaktiviert. Weitere Informationen finden Sie im Artikel zur Datei "rrdSecurity.props".


Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_rrd
Dateiname:cweb_rrd.html