L’architecture trois tiers s’utilise couramment pour construire des applications web. Le navigateur constitue le premier tiers. Vient ensuite le serveur d’application (tiers du milieu), qui se connecte à la base de données (troisième tiers). L’approche retenue pour relier les deux derniers tiers est stratégique à la fois en termes de performances et de portabilité.Elle repose sur quatre couches : liaison physique, middleware, API d’accès aux données du serveur d’application et enfin, couche d’abstraction. Chaque communauté technologique (Java, open source, Microsoft) s’appuie sur des techniques qui leur sont propres pour gérer les échanges entre base de données et serveur d’application.Bien que ces modèles divergent dans leur mise en ?”uvre, leur philosophie reste proche ; il existe donc des ponts d’une technologie à l’autre, de JDBC (Java DataBase Connectivity) à ODBC (Open DataBase Connectivity) par exemple.
1. La liaison physique
Le serveur d’application se connecte à la base de données via le protocole TCP/IP. Les deux serveurs n’ont donc pas besoin de se trouver sur la même machine ; il leur suffit d’être sur un même réseau local ou sur deux réseaux IP qui se voient.
2. Le middleware, un protocole réseau
Le serveur d’application et la base de données recourent ensuite à un protocole réseau (au-dessus de la couche transport) pour dialoguer entre eux, gérer l’authentification et les transactions, etc. Ce protocole, appelé également middleware, est soit natif et propriétaire (Oracle SQL*Net par exemple), soit standard (ODBC et JDBC, notamment).Inventé par Microsoft, ODBC s’est imposé en quelques années comme un standard de fait. Pour fonctionner, il suffit d’installer son socle (on le retrouve dans le panneau de configuration de Windows sous l’icône “Sources de données ODBC“), ainsi que les pilotes des bases de données auxquelles on souhaite accéder (Access, SQL Server, Oracle, etc.).Pour une même base de données, il existe plusieurs pilotes ODBC fournis par différents éditeurs. JDBC propose la même approche pour le monde Java. Il en va de même pour Perl avec DBD (DataBase Drivers). ODBC, JDBC et DBD fonctionnent sur le même modèle. L’interface de programmation (API JDBC, API ODBC et DataBase Interface [DBI] pour Perl) sert à accéder de façon homogène à diverses bases. Une fois ces deux couches installées (liaison physique et middleware), les deux serveurs sont capables de dialoguer entre eux.Certains middlewares comme ODBC améliorent la portabilité du code par la création d’un DSN (Database Server Name). Ce raccourci pourra être appelé directement depuis le code du développeur, lequel n’aura qu’à mentionner le nom du DSN (“ma base” par exemple) plutôt que de coder “en dur” l’adresse IP du serveur, le login, le mot de passe, etc. Si l’entreprise transfère ses données dans une nouvelle base, il lui suffira de modifier une ligne de code pour “rebrancher” l’application sur la nouvelle base.
3. Le langage de requête
Quel que soit le middleware utilisé, le langage SQL (Structured Query Language) sert à effectuer des opérations sur les données. Il autorise la sélection, l’ajout, la modification… des données en s’appuyant sur un langage simple mais puissant. La sélection de tous les enregistrements de la table “articles” portant sur “internet” s’exprime, par exemple, de la façon standard suivante : “SELECT * FROM articles WHERE theme=’internet’“.Ce langage n’offre toutefois pas la possibilité de tirer parti des fonctions propriétaires des bases de données, mais couvre en général 99 % des besoins du développeur. Les requêtes SQL sont véhiculées du serveur d’application à la base de données via le middleware.
4. Le modèle de données
L’ordre d’exécution de la requête SQL et sa définition s’effectuent directement dans le code. Pour ce faire, le modèle de données de chaque serveur d’application fournit une API qui masque l’hétérogénéité des différentes API de chaque middleware et base de données. Typiquement, le serveur d’application se connecte à la base en s’authentifiant, puis exécute une requête. Le modèle de données propose un ensemble de méthodes pour faciliter ces opérations.Ainsi, dans le cadre du serveur d’application PHP, l’accès à une base MySQL via ODBC utilisera les commandes “$connexion=odbc_connect (“dsn”, “login”, “password”)” et “odbc_exec($connexion, “SELECT * …”)“. La commande “odbc_connect()” sera ensuite traduite de l’API PHP vers l’API ODBC lors de l’exécution de la page.Comme le montre l’exemple suivant, les serveurs d’application proposent parfois plusieurs API propres à chaque base de données et middleware. PHP offre par exemple la possibilité de se connecter à une base Oracle via les fonctions “$conn = Ora_Logon()” et “Ora_Open()“. Dans ce second cas, les méthodes seront traduites directement dans l’API native d’Oracle (OCI).
5. La couche d’abstraction
La couche d’abstraction fournit une API de plus haut niveau afin d’améliorer encore la portabilité du code et de simplifier le développement. Grâce à elle, on utilise les mêmes fonctions pour se connecter à une base, exécuter une requête, etc., quels que soient la base et le middleware employés.Il s’agit de DBI pour Perl, de PEAR DB pour PHP et d’ADO (ActiveX Data Objects) pour Microsoft. Si l’on reprend l’exemple PHP précédent, la connexion à une base de données via ODBC ou en mode natif s’effectuera avec la même instruction “DB::connect($dsn);“.Le cas du serveur d’application de Microsoft se révèle un petit peu différent. ADO constitue à la fois une couche d’abstraction et un modèle de données dédié au serveur d’application Active Server Pages. L’éditeur s’appuie en effet sur une couche intermédiaire, OLE DB, de façon à unifier l’accès aux données depuis n’importe quel type d’application.
6. Choisir l’architecture adaptée
Portabilité et performance ne font malheureusement pas bon ménage. Plusieurs approches peuvent donc être adoptées selon l’intensité des dialogues entre le serveur d’application et les bases de données et les objectifs de l’entreprise. La première architecture privilégie les performances au détriment de la portabilité du projet.Elle consiste à relier le plus finement possible la base de données au serveur d’application. L’ensemble des technologies propriétaires de la base de données est donc utilisé. Chez Oracle, il s’agit par exemple du middleware SQL*Net et de l’API OCI8. Ce couplage fort autorise le développeur à piloter les procédures stockées et les autres fonctions non standard directement depuis son code.”OCIPLogon (“login”,”password”,”mabase”)” sert par exemple à se connecter à une base Oracle 8i depuis PHP. “OCIExecute()” et “OCIResult()” aident ensuite le développeur à récupérer les résultats de l’exécution d’une requête.L’autre approche privilégie la portabilité du code. Pour être portable, une application doit être faiblement couplée et s’appuyer sur un maximum de couches standard. Dans cette configuration, le middleware employé est ODBC dans le monde Microsoft, JDBC dans le monde Java et DBI (et ses dérivés) dans la communauté open source. Le développeur s’appuie ensuite sur la couche d’abstraction disponible la plus élevée (DBI, PEAR DB, etc.) et n’utilise que des requêtes au standard SQL.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
