Principes de base des applications multiniveaux dans Oracle 12c - Mannequins

Oracle 12c se rend compte que m ulti-tier applications sont la norme industrielle actuelle et composent plusieurs web, application et base de données serveurs fournissant du contenu aux clients légers avec présentation via un navigateur Web. Vous êtes-vous déjà demandé ce qu'il y a dans les coulisses lorsque vous vous connectez à une application Web pour effectuer des achats en ligne ou des opérations bancaires?

Le niveau client est simplement un navigateur Web accédant à un serveur Web. L'affichage du contenu à l'utilisateur est l'objectif principal du client dans cette architecture; aucun traitement réel n'a lieu à cette couche dans le navigateur. La présentation se produit le plus souvent via HTML (HyperText Markup Language), mais elle peut également être dans une applet Java ou un composant ActiveX et utiliser JavaScript pour une mise en forme et un contenu plus dynamiques.

La communication entre le navigateur et le serveur Web s'effectue via HTTP (HyperText Transfer Protocol) ou HTTPS pour les données sécurisées (cryptées). Les serveurs Web agissent de manière conceptuelle en tant qu'auditeurs Web; ils reçoivent des demandes des navigateurs et retournent des ensembles de résultats formatés avec peu de traitement par eux-mêmes. Une fois sur le serveur Web, la requête du navigateur est analysée et envoyée au serveur d'application approprié pour traitement.

Le composant du serveur d'applications peut se trouver sur le même serveur physique que le serveur Web ou sur un autre serveur physique. De loin, le serveur Web le plus courant est Apache, ou l'un de ses dérivés commerciaux, avec plus de 50% de part de marché selon Netcraft.

Au niveau du serveur d'application, la demande de l'utilisateur est traitée à l'aide de la logique d'application appropriée. Une méthode très courante consiste à utiliser un serveur d'applications Java, tel que Tomcat, Orion ou Glassfish. Dans ce cas, la logique du programme est exécutée à l'intérieur d'une machine virtuelle Java (JVM), qui sert d'environnement d'exécution pour le code du programme.

Oracle Fusion Middleware (OFM) est un autre outil populaire. Dans OFM, le programme peut fonctionner sous Oracle Forms, Reports, Discoverer ou même Java via Oracle Containers pour J2EE (OC4J). Quel que soit le produit, c'est dans le composant du serveur d'applications que la logique de l'application est exécutée.

Pendant le traitement sur le serveur d'applications, il est courant d'avoir besoin d'un accès à la base de données pour interroger, créer, mettre à jour ou supprimer des données. Le serveur d'applications communique avec le serveur de base de données via des protocoles, tels que JDBC ou Oracle Net, pour accéder aux données. Pendant ce temps, le serveur d'applications accède à la base de données au nom de l'utilisateur effectuant la demande d'application.

Plutôt que de se connecter en tant qu'utilisateur nommé distinct, tel que JSMITH, le serveur d'applications se connecte à l'aide d'un compte Web générique (tel que WEB_USER). Plusieurs connexions simultanées du serveur d'applications à la base de données forment un pool de connexions qui permet à toute connexion à la base de données d'accéder aux données d'une requête. La mise en pool des connexions est un avantage en termes de performances car seules quelques connexions de base de données peuvent traiter des milliers de requêtes pour le compte de nombreux utilisateurs.

Une fois connecté à l'instance de base de données, l'utilisateur Web générique interroge ou exécute DML au nom du serveur d'applications, qui traite une requête utilisateur réelle. L'utilisateur Web associé à la connexion n'a pas de propriété de schéma dans la base de données; il dispose uniquement des autorisations nécessaires pour accéder ou mettre à jour les données au nom du serveur d'applications.

Pendant cette période, les rôles de base de données, les autorisations et les autorisations sont utilisés. De plus, une logique de programme de base de données implémentée en PL / SQL via des procédures, des fonctions et des packages est souvent exécutée.

Une fois le jeu de résultats de données généré sur le niveau de base de données, il est renvoyé au serveur d'applications pour un traitement supplémentaire. Ensuite, les résultats sont relayés via le serveur Web et à travers le réseau pour être présentés à l'utilisateur via son navigateur Web.

Cela semble compliqué avec tous les différents composants? Vous pouvez le penser au premier abord, mais de bonnes raisons existent pour briser le système en composants Web, applicatifs et de base de données:

• Vous pouvez utiliser des composants provenant de différents fournisseurs dans une configuration «best of breed». Par exemple, vous pouvez utiliser une instance de serveur Web Apache gratuite couplée à Tomcat ou Glassfish pour un composant de serveur d'applications bon marché. Puis reliez cela à la puissance de la base de données Oracle, et vous avez un système solide à moindre coût!

• À mesure que de nouveaux utilisateurs se connectent, vous pouvez ajouter d'autres instances de serveur Web, d'application ou de base de données pour augmenter votre puissance de traitement. Plutôt que d'acheter de plus gros serveurs, il suffit d'acheter des serveurs plus petits.

• Une fois que vous avez plusieurs serveurs, vous gagnez en tolérance de panne. C'est ce qu'on appelle le clustering. Si un serveur Web tombe en panne ou que le serveur d'applications a besoin de maintenance, aucun problème: les serveurs redondants prennent en charge la charge de travail.

Nous espérons que ces avantages démontrent pourquoi les architectures de systèmes multiniveaux sont la norme de l'industrie et ont dépassé les systèmes client-serveur.