Abb. 17 zeigt eine effiziente Lösung für Online-Banking, die ähnlich aufgebaut ist wie das in B2C-Netz beschriebene B2C-Netz. Alle Clientanforderungen werden durch die Firewall an einen Dispatcher übertragen, der die Übertragungen gemäß dem Internet-Protokoll verteilt. HTTP-Anforderungen werden an einen Cluster von Proxyservern mit aktiven Caches übermittelt, die stellvertretend für die Webserver auftreten. Den Proxyservern sind Metrikserver zugeordnet, die Lastausgleichsdaten für den Dispatcher bereitstellen. Diese Anordnung verringert die Netzlast auf den Webservern und erstellt einen zusätzlichen Puffer zwischen ihnen und dem Internet.
HTTPS-Anforderungen werden an ein sicheres Netz weitergeleitet, das für die Clients persönliche Finanzinformationen bereitstellt und die Ausführung von Online-Banking-Transaktionen erlaubt. Ein Cluster von erweiterten Proxyservern erlaubt die Skalierbarkeit der Site. Diese Proxyserver unterstützen das Caching von dynamischen Webinhalten und das Assemblieren von Seitenfragmenten, die gemäß den Regeln des Protokolls ESI (Edge Side Includes) geschrieben wurden. Eine Verschlüsselungskarte (Cryptocard in der folgenden Abbildung) verwaltet die SSL-Handshakes, wodurch sich der Verarbeitungsaufwand für den Proxyserver-Host erheblich verringert. Access Manager (früher Policy Director) steuert die Clientauthentifizierung.
Eine Gruppe von Anwendungsserver-Clustern verteilt die Verarbeitung von Anforderungen, indem die in den EJB-Komponenten enthaltene Geschäftslogik von der in Servlets und JSP-Dateien enthaltenen Präsentationsschicht getrennt wird. Jeder dieser Cluster wird von einem eigenen Sitzungsserver verwaltet.
Das folgende Szenario umfasst Load Balancer und Caching Proxy.
Wichtig: Caching Proxy ist mit folgender Ausnahme in allen Edge-Components-Installationen verfügbar: