Architectures à trois niveaux
WebSphere Application Server fournit la couche de logique applicative dans une architecture à trois niveaux, ce qui permet aux composants client d'interagir avec les ressources de données et les applications existantes.
Le schéma ci-dessous présente les trois niveaux. Les niveaux sont logiques. Ils peuvent ne pas être exécutés sur le même serveur physique.

Premier niveau. La responsabilité de la présentation et de l'intervention de l'utilisateur dépend des composants de premier niveau. Ces composants client permettent à l'utilisateur d'interagir avec les processus du deuxième niveau de façon sécurisée et intuitive. WebSphere Application Server prend en charge plusieurs types de client. Les clients n'accèdent pas directement aux services du troisième niveau. Par exemple, un composant client fournit un formulaire à l'aide duquel un client commande des produits. Le composant client soumet cette commande aux processus du deuxième niveau, qui vérifient les bases de données du produit et effectuent les tâches nécessaires à la facturation et à l'envoi.
Deuxième niveau. Les processus de deuxième niveau sont généralement considérés comme la "couche de logique applicative". Ces processus gèrent la logique applicative et peuvent accéder aux services du troisième niveau. C'est dans la couche de logique applicative que s'effectue la plus grande partie du traitement. Plusieurs composants client peuvent accéder simultanément aux processus de deuxième niveau de sorte que cette couche de logique applicative doit gérer ses propres transactions.
Dans l'exemple précédent, si plusieurs clients tentent de passer une commande pour le même article, dont il ne reste qu'un exemplaire, la couche de logique applicative doit déterminer qui a droit à cet article, mettre à jour la base de données pour qu'elle reflète l'achat et informer les autres clients que l'article n'est plus disponible. Sans couche de logique applicative, les composants client accèdent à la base de données des produits directement. La base de données doit gérer ses propres connexions, généralement en verrouillant un enregistrement auquel un utilisateur accède. Un verrouillage peut avoir lieu lorsqu'un article est placé dans un panier électronique, empêchant ainsi d'autres utilisateurs de vouloir l'acheter. La séparation du deuxième et troisième niveau réduit la charge qui pèse sur les services du troisième niveau, prend en charge une gestion des connexions plus efficace et permet d'améliorer les performances globales du réseau.
Troisième niveau. Les services du troisième niveau sont protégés d'un accès direct de la part des composants client qui se trouvent sur un réseau sécurisé. L'interaction doit avoir lieu par le biais des processus de deuxième niveau.
z/OS peut réduire le deuxième
et le troisième niveau en un environnement physique z/OS, tout en conservant la
sécurité et les avantages logiques des systèmes à niveau unique.
Communication entre les niveaux. Les trois niveaux doivent communiquer entre eux. Des protocoles standard ouverts et des API exposées simplifient cette communication. Vous pouvez créer des composants client dans n'importe quel langage (par exemple, Java™ ou C++). Ces clients sont exécutés sur un quelconque système d'exploitation, en communiquant avec la couche de logique applicative. La conception des bases de données du troisième niveau peut être variée, à partir du moment où la couche de logique applicative peut les interroger et les manipuler. La clef de voûte de cette architecture est la couche de logique applicative.