SPARQL Protocol and RDF Query Language/La programmation Web

Début de la boite de navigation du chapitre

Pour faire de la programmation Web, il faut comprendre deux choses :

• Qu'est-ce que la programmation ?
• Qu'implique l'architecture du Web des données ?

fin de la boite de navigation du chapitre

Ce cours suppose que vous n'avez peut-être jamais développé de votre vie, ou presque. Ainsi, nous commençons par les bases, afin que vous maîtrisiez le vocabulaire minimum pour comprendre ce cours.

La programmation

Des ingrédients : des variables

Un exemple suffira à comprendre à quoi une variable peut servir.

On a tous eu entre les mains une publicité faussement personnalisée du type :

"Bonjour Madame Toutlemonde
Vous avez gagné notre canapé extra-cuir lors du tirage du 20/12/2008."

Il est clair que l'entreprise qui envoie cette publicité possède une base de données avec de nombreux noms.

Le programme qui produit ce texte utilise les valeurs Madame, Toutlemonde et la date, qu’il va insérer dans du texte figé.

On dit alors que le programme utilise des variables comme civilité, nom et date.

Une recette : des instructions

Programmer, c’est donner une suite d'instructions à une machine, comme on donne une recette de cuisine à un cuisinier.

La seul difficulté est que la machine ne comprend une recette que si la recette peut être traduite en binaire avec une instruction à la fois.

De manière linéaire

Un programme avance, instruction par instruction, de façon linéaire.

Dans un programme, deux types de constructions peuvent s'éloigner de cette linéarité :

1. L'instruction d'itération.
2. L'instruction de sélection.

Avec des itérations

Quand on a une action affreusement répétitive.

Exemple d'action répétitive :

Découper les trois plaques de chocolat en carrés individuels.

En programmation, on ne va pas dire un grand nombre de fois : détache le carré de chocolat, détache le carré de chocolat, détache le carré de chocolat...

On va plutôt faire ce que l’on nomme une itération (ou boucle), du genre :

Pseudo-code d'une itération tant que :

tant qu’il y a des carrés de chocolat à détacher { (1)
    détache le carré de chocolat                   (2)
}                                                  (3)

Ce minuscule programme va lire la condition en ligne 1 puis entre dans la boucle, délimitée par les accolades en ligne 1 et 3, et va répéter les instructions de cette "boucle" tant que la condition est vraie.

Remarque

Il y a plusieurs sortes d'itérations dans chaque langage, mais le comportement entre langages est le même. Seule la syntaxe peut différer.

Avec des sélections

Il arrive souvent qu'on doive faire une action que sous certaines conditions.

Exemple de sélections qui s'excluent mutuellement

"Pour faire une mousse au chocolat. 
Si j’ai 6 gourmands, je casse 8 œufs, 
si j’ai 6 personnes au régime, je casse 4 œufs, 
mais par défaut, une bonne mousse, c’est 6 œufs pour 6..."

Ici le cheminement logique linéaire se sépare en trois voies parallèles, un peu comme des rails, puis se regroupe à nouveau à la fin.
Le programme ne doit passer que par une, et une seule, des trois voies.

Pseudo-code d'instructions de sélection

si gourmand{                         1
     casse 8 œufs                    2
}sinon si régime{                    3
     casse 4 œufs                   4
}sinon{                              5
     casse 6 œufs                   6
}                                    7
Bien mélanger...                     8

En résumé

Programmer, c’est finalement ramener toute problématique à l'une des trois possibilités suivantes :

• une instruction qui s'exécute automatiquement,
• une instruction qui s'exécute autant de fois que nécessaire dans une boucle,
• une instruction qui s'exécute sous une condition.

Ajoutez à tout cela un certain nombre de variables que l’on manipule joyeusement...

Et vous avez les grandes lignes de la programmation.

Application Web

Une application Web est un programme qui :

• est accessible grâce à une adresse Web ;
• fonctionne à travers un navigateur Web.

Les navigateurs Web sont de plus en plus intégrés aux systèmes d'exploitation. Il est maintenant difficile de faire la différence entre un pur navigateur et un navigateur intégré. On va considérer comme une application Web toute application qui utilise Internet en respectant les technologies du Web comme HTTP, HTML, etc.

Pour simplifier, nous allons considérer qu’il y a deux familles d’applications Web :

1. les applications Client-Serveur
2. les applications 3-tiers ou architectures 3-tiers

Application Client-Serveur

Une application Client-Serveur partage son fonctionnement entre la machine de l'utilisateur, ou poste client, et une machine quelque part sur le réseau, ou machine serveur. Un serveur peut répondre à plusieurs clients simultanément.

Il y a trente ans, les machines étaient très coûteuses. Il était donc moins coûteux de centraliser les ressources dans un serveur central et de mutualiser ses ressources via des postes clients moins coûteux.

Depuis, il existe un va-et-vient entre ce que l’on appelle une architecture client léger ou client lourd.

Client lourd

Un client lourd est une application Web où le poste client est très sollicité. Par exemple, un jeu vidéo en Flash demande beaucoup de ressources processeurs pour le graphisme et le serveur n'est là que pour permettre la communication entre les joueurs, afin de connaître leur position dans le jeu.

Avantage : le réseau est peu sollicité pour transmettre des données. C'était idéal au début de l'Internet quand le débit était encore faible.

Inconvénient : il faut avoir des machines puissantes. Les applications ne pouvant être compatibles avec toutes les machines, les problèmes de déploiement sont un casse-tête.

Client léger

Un client léger, c’est le contraire. Le serveur fait tous les calculs et transmet aux clients uniquement ce qu’ils doivent afficher. C'était le choix d'architecture qui avait été retenu dans le passé, avant que le Web ne se développe, pour économiser des ressources côté client.

Avantage : Avec la miniaturisation, tous les circuits électroniques sont des clients légers. Ils peuvent afficher des applications Web sur une montre, des lunettes, le miroir, la télévision, etc.

Inconvénient : un client léger doit sans cesse faire appel à un serveur. Le débit nécessaire est donc important. De plus, toute votre vie transite à chaque instant sur Internet sans sécurité particulière le plus souvent.

Bien que les postes clients soient plus puissants que dans le passé et que les services pourraient se décharger sur les postes clients pour diminuer leurs coûts d'infrastructures, la tendance continue à faire porter les coûts sur les serveurs, et non sur les postes clients. Par exemple, Google dépense environ un milliard de dollars par trimestre pour supporter la charge de ses services.

Le choix de développer ou non une application Web à client léger n'est plus dû à des limites technologiques, mais à des considérations économiques. Les services étant bien souvent gratuits, les utilisateurs de ces services, à travers leurs données, sont devenus les produits que ces services vendent à leurs clients, comme le fait Facebook.

Pour faciliter la réutilisation de ces données exploitables dans d'autres applications, on a ajouté un niveau, pour séparer les données de l’application Web.

L'architecture 3-tiers pour une application Web

Exemple d'architecture en 3 couches

Voici la définition d'une architecture 3-tiers :

L'architecture 3-tiers est un modèle logique d'architecture applicative qui vise à séparer très nettement trois couches logicielles au sein d'une même application ou système à modéliser. Les applications qui respectent cette architecture 3-tiers sont représentées comme un empilement de trois couches (ou étages, ou niveaux, ou strates) dont le rôle est clairement défini :

• la présentation des données : correspondant à l'affichage, la restitution sur le poste de travail, le dialogue avec l'utilisateur ;
• le traitement métier des données : correspondant à la mise en œuvre de l’ensemble des règles de gestion et de la logique applicative ;
• l' accès aux données persistantes : correspondant aux données qui sont destinées à être conservées sur la durée, voire de manière définitive.

On peut développer l'architecture 3-tiers de deux manières :

• Avec une seule base de données (même si elle est sur plusieurs serveurs)
• Avec une multitude de sources de données et de destinations.

Nous allons étudier ce que ces deux manières de développer une application Web vont changer dans l'avenir du Web.

Avec une seule base de données

Comme nous l'avons vu dans la partie précédente, dans la réalité, le traitement et la présentation peuvent être partagés entre le poste client et un (ou des) serveur(s). C'est la même chose pour les données persistantes, qui peuvent être stockées temporairement dans le navigateur du poste client tant que la connexion à Internet n’est pas rétablie. Et elles seront de toute façon stockées dans une seule base de données.

Avantage : Une seule base de données, c’est d’abord un seul problème à résoudre dans une architecture qui peut être complexe (multi-serveur, backup, etc.). C'est bien souvent la solution choisie par l'architecte Web.

Inconvénient : Les données séparées de leur contexte ont une valeur moindre. Par exemple, vous activez la géolocalisation de votre téléphone avec un service et votre téléphone est utilisé pour payer votre baguette avec un autre service. Séparément, les données de géolocalisation et de paiement ont peu de valeur. Cependant, si les données sont croisées, on pourra proposer à votre boulanger de vendre de la publicité sur votre téléphone quand vous passez à proximité de sa boulangerie.

Cet inconvénient est en train d’être résolu avec le cloud computing (ou infonuagique), car on propose maintenant aux services d’utiliser la même base de données entre eux et à moindre coût. Le premier symptôme est la capacité des bandeaux de publicité d'afficher le même type d'électroménager que vous êtes en train de rechercher sur Internet.

La limitation liée au non-croisement des données était aussi une assurance temporaire contre les dérives du croisement abusif (produit de maquillage → appartenance ethnique ; géolocalisation durant une manifestation → appartenance politique ; achat d'un kit de survie aux États-Unis → terrorisme, etc.).

Le croisement des données est possible, car, technologiquement, on peut maintenant stocker des quantités de données phénoménales dans une seule base de données pour en faciliter le traitement, comme avec le service gData de Google.

Les questions qui se posent maintenant, sont :

• À qui appartiennent ces données ?
• Les personnes concernées par ces données sont-elles informées ?
• Peut-on contrôler nos données ?

Ceux-là mêmes qui vivent de vos données vous répondrons "non", affirmant qu’il n'y a pas de solutions technologiques à ces problèmes. La réalité est toute autre avec la prochaine rupture technologique, que l’on nomme : Web des données ou, en anglais, Linked Data.

Avec le Linked Data

Une application 3-tiers utilisant le Linked Data, ou Web des données, est une application qui utilise les données mises à sa disposition sur le Web en utilisant les recommandations du W3C. Ces données peuvent être gratuites et librement accessibles, on dit alors que l’application utilise le Linked Open Data.

Jusqu'à présent, les applications utilisaient pour la plupart une unique base de données avec, comme principal langage d'enregistrement, le SQL. Avec le Web des données, les applications vont utiliser un nouveau langage : SPARQL.

SPARQL est un langage encore jeune. Ses premières implémentations, comme avec 4Store, sont encore limitées mais les recommandations en cours de validation vont permettre de commencer à imaginer et développer de nouveaux services pour, par exemple :

• identifier l'origine des données dans une base de données (pour savoir à qui appartiennent ces données)
• interroger les données de manière interopérable, transparente et sécurisée (pour permettre à chacun d’identifier qui possède ses données personnelles)
• écrire dans n’importe quelle base de données (pour permettre à chacun de modifier ses données personnelles)
• autoriser ou non un service tiers de lire des données personnelles dans son serveur domestique
• etc.

Nous allons, dans les prochains chapitres, présenter les bases du langage SPARQL 1.0 et 1.1 pour que vous puissiez créer vos propres services.

Pour commencer, nous allons imaginer une application 3-tiers avec le Web des données.

Étude de cas

Dans ce chapitre, nous avons décrit un programme en utilisant un "pseudo-langage", c'est-à-dire que l’on a décrit en français ce qu'une machine devrait faire. Nous allons continuer à écrire du pseudo-code dans l'exercice suivant.

Exercice :

En pseudo-langage, décrire le programme du service CV 3.0. Ce service va rechercher sur le Web des CV pour recruter des personnes ayant des compétences en SPARQL, PHP, .NET ou Java. Les sources des CV sont des services payants, par exemple Keljob, avec 0,15 € par CV, et Monster, avec 0,07 € par CV. Le service prend 10 % de marge et autorise uniquement le paiement par CB.

Disons que la réponse à cet exercice commencerait ainsi :

//commentaire : affichage permanent
affiche 'Merci d’avoir choisi CV3.0 !
Choisissez les compétences que vous recherchez : SPARQL, PHP, .NET, Java ?';
Si réponse{
         recueille competence_choisie
         //etc. 
}

Solution

Il y a toujours plusieurs possibilités. Cette étude de cas illustre la capacité à mettre en œuvre plusieurs sources de données avec le protocole SPARQL avec une facturation simpliste, mais différente pour chaque source.

Voici une solution envisageable :

//commentaire : affichage permanent
affiche 'Merci d’avoir choisi CV3.0 ! Choisissez les compétences que vous recherchez : SPARQL, PHP, .NET, Java ?';
Si réponse {
     recueille competence_choisie;

     affiche ‘Indiquer le prix que vous ne voulez pas dépasser';
     Si réponse {
         recueille prix_maximum;

         affiche 'Entrez votre carte bleue';
         tantque info carte bleue pas entrée{
	 affiche 'Entrez votre carte bleue';
         }
         affiche 'Entrez votre code';
         tant que code pas entré ou pas bon{
	 affiche 'Entrez votre code';
         }
         recueille code;
         
	affiche 'Veuillez attendre !';
	//Initialisation de la liste des sources de données
	initialise liste_des_sources_de_données;
	Ajoute à liste_des_sources_de_données "http://keljob/sparql/" (0.15 €/résultat);
	Ajoute à liste_des_sources_de_données "http://monster/sparql/" (0.07 €/résultat);

        //Initialisation de la liste des personnes possédant les compétences recherchées
        initialise liste_des_candidats;
        //Initialisation du prix à payer
        prix_payé_total = 0;

        Tant qu’il reste une source à interroger dans la liste_des_sources_de_données  {
	 si la source est accessible {
		nb_candidats_trouvés = nb de candidats ayant la competence_choisie dans la source;
                prix_facturé_par_la_source = nb_candidats_trouvés x prix_de_la_sources_de_données;
		
                //ajoute une marge de 10% au prix final estimé
                Si ((prix_payé_total + prix_facturé_par_la_source ) x 1.1) < prix_maximum {
                        débite prix_facturé_par_la_source  du compte de l'entreprise;
		 obtient les candidats_trouvés ayant la competence_choisie dans la source;
                        ajoute dans liste_des_candidats les candidats_trouvés; 		          
		 prix_payé_total = prix_payé_total + prix_facturé_par_la_source;
                }
	 }
    }
//ajoute une marge de 10 %
prix_final = prix_payé_total x 1.1; 	
débite le prix_final de son compte;
affiche 'Merci, et à la prochaine fois chez CV3.0 !';
affiche liste_des_candidats;
}