Les scénarios métier suivants utilisent les composants WebSphere Application Server Edge avec WebSphere Application Server Proxy. Il s'agit de solutions robustes du point de vue architectural, qui ont été testées afin d'offrir performances, disponibilité, évolutivité et fiabilité d'excellence.
Le site Web de commerce électronique de base est un réseau B2C. Dans la première phase de croissance d'Internet, les métiers consistaient simplement à créer une présence Web. Les informations d'entreprise et les catalogues de produits sont convertis au format numérique et mis à disposition sur le site Web. Il est possible de faire des achats en fournissant des adresses électroniques, des numéros de téléphone et de télécopie, et même des formulaires automatisés. Toutefois, les véritables achats en ligne ne sont pas disponibles. Toutes les transactions font l'objet d'un temps d'attente inhérent, en raison du traitement humain des commandes.
Dans la deuxième phase, les entreprises suppriment ce temps d'attente et rationalisent leurs ventes en mettant en place des paniers sécurisés pour les achats directs en ligne. La synchronisation avec les bases de données d'entrepôt et l'intégration aux systèmes bancaire sont des opérations essentielles pour mener à bien ces transactions de vente. Tout produit indisponible ne peut être vendu, le compte d'un client ne pouvant donc être débité pour cet article. De même, un produit ne peut pas être déstocké et expédié à un client tant qu'une transaction financière valide n'a pas eu lieu.
Dans la troisième phase, le site Web de la société évolue en site de présentation dynamique dans lequel le consommateur devient un client et est associé à un contenu personnalisé. Le scénario ci-dessous concerne Load Balancer et le proxy WebSphere Application Server.
Phase 1 : La figure ci-dessous présente un petit site Web commercial permettant de consulter aisément le catalogue.
Toutes les requêtes client passent par le pare-feu vers un répartiteur qui les achemine vers un cluster de serveurs proxy dotés de caches actifs faisant office de serveurs de substitution vers les serveurs Web. Les serveurs Metric sont colocalisés avec les serveurs proxy afin de fournir des données d'équilibrage de charge au répartiteur. Cette disposition permet de limiter la charge du réseau sur les serveurs Web et de les isoler de tout contact direct avec Internet.
Phase 2 : La figure suivante illustre la deuxième phase d'évolution d'un site Web commercial conçu pour faciliter et accélérer la consultation des catalogues et sécuriser les paniers des éventuels clients.
Toutes les demandes de client sont acheminées vers la branche concernée du réseau par un répartiteur, qui les sépare en fonction du protocole Internet. Les requêtes HTTP et HTTPS partent respectivement vers un site Web statique et le réseau d'achat. Le principal site Web statique est toujours servi par un cluster de serveurs proxy dont les caches actives remplacent les serveurs Web. Cette partie du réseau reproduit le réseau de la première phase.
La partie consacrée au commerce électronique du site Web est également servie par un cluster de serveurs proxy. Toutefois, les noeuds Caching Proxy sont étendus grâce à plusieurs modules de plug-in. Le protocole d'établissement de liaison SSL est déchargé sur une carte de matériel de cryptographie, et un processus d'authentification est lancé par l'intermédiaire du plug-in Access Manager (anciennement Policy Director). Un plug-in Dynamic Caching stocke les données communes afin de réduire la charge de travail sur WebSphere Application Server. Le cas échéant, un plug-in du serveur d'applications invalide les objets dans Dynacache.
Toutes les applications de panier sont rassemblées dans la base de données du client utilisée pour authentifier l'utilisateur. Cela permet d'éviter à l'utilisateur d'entrer deux fois ses informations personnelles dans le système (une fois pour l'authentification et une fois pour les achats).
Ce réseau répartit le trafic en fonction de l'utilisation du client, en supprimant l'authentification SSL et les paniers de commerce électroniques gourmands en temps processeur du site Web principal. Ce site Web double permet à l'administrateur de réseau d'optimiser les différents serveurs afin d'offrir d'excellentes performances en fonction du rôle de chacun d'eux dans le réseau.
Phase 3 : La dernière figure illustre la troisième phase de l'évolution d'un réseau B2C, le site Web statique adoptant une méthode de présentation dynamique. Le cluster de serveurs proxy a été étendu pour prendre en charge la mise en cache du contenu Web dynamique et l'assemblage des fragments de page conformément au protocole ESI (Edge Side Includes).
Au lieu d'utiliser des mécanismes d'inclusion SSI pour concevoir des pages Web sur les serveurs de contenu, puis de propager dans tout le réseau ces pages spécifiques au client impossible à mettre en cache, les mécanismes ESI permettent d'assembler des pages à partir d'un contenu mis en cache en périphérie d'un réseau, réduisant la bande passante et diminuant le temps de réponse.
Les mécanismes ESI sont essentiels dans la troisième phase du scénario, dans lequel chaque client reçoit une page d'accueil personnalisée provenant du site Web. Les blocs de construction de ces pages sont extraits d'une série de serveurs WebSphere Application. Les serveurs d'applications contenant une logique métier sensible et assemblés pour sécuriser les bases de données, sont protégés par un pare-feu.
Ce scénario concerne Load Balancer et le proxy WebSphere Application Server.
La figure ci-dessous illustre une solution bancaire en ligne efficace analogue au réseau B2C décrit dans la section Réseau B2C. Toutes les requêtes client passent par le pare-feu vers un répartiteur qui sépare le trafic en fonction du protocole Internet. Les requêtes HTTP accèdent à un cluster de serveurs proxy dotés de caches actifs faisant office de serveurs de substitution pour les serveurs Web. Les serveurs Metric sont colocalisés avec les serveurs proxy afin de fournir des données d'équilibrage de charge au répartiteur. Cette disposition permet de limiter la charge du réseau sur les serveurs Web et de les séparer d'Internet par une mémoire tampon supplémentaire.
Les requêtes HTTPS sont transmises à un réseau sécurisé conçu pour fournir des informations financières personnelles au client et autoriser les transactions bancaires en ligne. Un cluster de serveurs proxy étendus assure l'évolutivité du site. Ces serveurs proxy prennent en charge la mise en cache du contenu Web dynamique et de l'assemblage des fragments de page écrites conformément au protocole ESI (Edge Side Includes). Une carte de matériel de cryptographie gère les établissements de liaison SSL, réduisant de manière significative le traitement requis de l'hôte du serveur proxy, et un Access Manager (anciennement Policy Director) dirige les authentifications client.
Un ensemble de clusters de serveurs d'applications répartit le traitement des requêtes en séparant la logique métier (contenue dans les composants EJB) de cette couche présentation (contenue dans les servlets et les fichiers JSP). Chacun de ces clusters est géré par un serveur de session différent.
Ce scénario concerne Load Balancer et le proxy WebSphere Application Server.
La figure ci-dessous illustre un réseau de portails Web conçu pour prendre en charge un important volume de trafic tout en fournissant à chaque client un contenu personnalisé. Pour limiter la charge de traitement sur les différents serveurs, aucune partie du réseau n'assure le trafic SSL. Etant donné que le portail ne livre pas de données sensibles, la sécurité n'est pas une question essentielle. Il est important de maintenir une sécurité moyenne et non corrompue des bases de données contenant les ID client, les mots de passe et les paramètres, cette exigence ne compromettant pas les performances du reste du site Web.
Toutes les requêtes client passent par le pare-feu vers un répartiteur qui équilibre la charge du réseau grâce à un cluster de serveurs proxy dotés de caches actifs faisant office de serveurs de substitution vers les serveurs Web. Les serveurs Metric sont colocalisés avec les serveurs proxy afin de fournir des données d'équilibrage de charge au répartiteur.
Le site Web dynamique actuel est un cluster de serveurs d'applications générant des fragments ESI transmis aux serveurs proxy pour assemblage. Etant donné quel les questions liées à la sécurité sont secondaires, chaque serveur d'applications lance toutes les fonctions nécessaires à la construction du site Web. Tous les serveurs d'applications sont identiques. Si l'un d'eux tombe en panne, le serveur de session peut acheminer les requêtes vers les autres serveurs, assurant la haute disponibilité de l'ensemble du site. Cette configuration permet également une escalade rapide du site Web en cas de trafic excessif (l'hébergement d'un événement particulier par le portail, par exemple). D'autres serveurs proxy et serveurs d'applications peuvent rapidement être configurés dans le site.
Tout le contenu statique (les fichiers image et le texte prédéfini, par exemple) est stocké sur des serveurs Web distincts, ce qui permet de le mettre à jour sans risque de corrompre les serveurs d'applications plus complexes.