Ch. 2 — Architecture client-serveur et ODBC

Après le chapitre de rappels, ce deuxième cours de la ressource répond à une question très concrète : plusieurs personnes doivent accéder à la même base en même temps — comment ? La réponse tient en deux idées : le modèle client-serveur, qui organise les programmes, et ODBC, qui standardise la manière dont un client dialogue avec n'importe quel serveur de bases de données. C'est aussi la première brique du web back-end : un site web dynamique, c'est d'abord un client (le navigateur) qui parle à un serveur.

1. Le problème : une base, plusieurs utilisateurs

En situation professionnelle, une base de données n'est jamais consultée par une seule personne. Le cours en donne trois exemples :

• les différentes agences d'une banque accèdent en même temps au solde des comptes ;
• les différents magasins d'une chaîne de vêtements consultent simultanément les stocks ;
• tous les étudiants consultent leurs notes au même moment.

Il n'y a qu'une seule base, mais plusieurs logiciels qui y accèdent depuis des machines différentes. Il faut donc un programme qui garde les données et répond aux demandes : le serveur. Les programmes qui demandent sont les clients.

Le principe général

Le cours insiste : client-serveur est un principe général, pas une technologie propre aux bases de données.

• Le serveur est un serveur de ressources communes : il fournit un service.
• Un client est un programme qui s'adresse à un programme serveur exécuté sur une machine distante, pour échanger des informations et des services.
• En général, plusieurs clients accèdent simultanément au même serveur.

C'est l'un des axes les plus importants de l'informatique distribuée. Et ce principe est partout — le cours en dresse la liste :

2. Les ports : trouver le bon service

Un serveur physique peut héberger plusieurs serveurs (web, base de données, messagerie…). Comment le client sait-il à qui parler ? Chaque serveur scrute un ou plusieurs ports, identifiés par un numéro sur 2 octets (donc de 0 à 65535). Les numéros inférieurs à 1024 sont réservés à l'administrateur.

Certains numéros sont standardisés — les connaître évite de chercher pourquoi une connexion échoue :

Retenez au minimum 5432 (PostgreSQL) : c'est celui que vous utilisez à chaque connexion psql -h psqlserv, et 80/443 (web). La combinaison adresse IP + port identifie sans ambiguïté « la machine, puis le service sur cette machine ».

3. ODBC : parler à n'importe quel serveur

Le problème historique

Jusqu'à récemment, une application client-serveur était construite par un même concepteur qui fournissait le client et le serveur. Conséquence : impossible de changer l'un sans l'autre. Il fallait permettre la connexion de n'importe quel client avec n'importe quel serveur — d'où la naissance de protocoles standardisés :

• ODBC (Open DataBase Connectivity) — proposé par Microsoft, standard de fait du monde Windows ;
• JDBC (Java DataBase Connectivity) — son équivalent pour Java, que vous utiliserez dans les prochains TP.

Ces protocoles sont codés dans des pilotes (drivers) : des logiciels qui se chargent de la traduction entre le langage standard et le protocole propre à chaque SGBD.

Le gestionnaire ODBC et ses pilotes

L'architecture se lit en trois couches :

L'avantage décisif : la base utilisée côté serveur peut être interchangée sans aucune modification du développement fait dans la partie cliente. On peut même utiliser la puissance d'un mainframe (IBM Z900, AS400…) pour héberger les données, avec la souplesse d'Access pour construire formulaires et états.

Les pilotes disponibles

• En standard : SQL Server Driver.
• Avec MS-Office : pilotes dBASE, Excel, FoxPro, Access, Text.
• Pour les autres SGBD : c'est le concepteur du serveur qui fournit le pilote — pour PostgreSQL, le pilote s'appelle PostgreSQL Unicode.

Le cas Access : front-end / back-end

Access peut jouer les deux rôles à la fois. Sa partie front-end (formulaires, états, requêtes) reste l'interface cliente ; les données, elles, vivent dans le back-end — n'importe quel serveur SGBD relié par ODBC. C'est exactement ce que vous manipulerez au TP 3.02 : Access en client, PostgreSQL en serveur, et même une jointure entre une table Access et une table PostgreSQL.

4. La nouvelle question : que mettre où ?

Le cours se termine par un changement de problème. Avant, la seule question était « quel bon concepteur choisir ? ». À l'heure du client-serveur, la question devient : comment répartir l'application entre le serveur et le client ? Que met-on côté serveur (les données, la logique d'accès), que met-on côté client (l'interface, une partie de la logique) ?

C'est cette question qui irrigue toute la suite de la matière : JDBC, architectures web, MVC, REST — autant de réponses différentes à la même question de répartition.

Mots clés

Auto-évaluation

---