Samsung a annoncé dans un communiqué que la firme a développé une composante essentielle de son réseau 5G, en réussissant à transmettre des données à la vitesse de 1 Gbps sur une distance de deux kilomètres séparant deux terminaux.
À l’heure actuelle, les réseaux 4G LTE peuvent seulement atteindre un maigre 75 mégabits par seconde (Mbps), et habituellement seulement environ le quart ou le tiers. Pour mettre ces caractéristiques en perspective, avec une connexion 1 Gbps vous seriez en mesure de télécharger un film de Nicolas Cage sur votre téléphone en full HD en moins d’une minute…

Les indicateurs techniques ? Le nouveau réseau de Samsung utilise une bande fréquence de 28 GHz. Samsung aurait utilisé 64 antennes pour disposer d’un tel transfert de données, et croit qu’elle peut commercialiser et mettre en œuvre leur réseau 5G en 2020. La Commission européenne s’attend à avoir sa propre technologie sans fil 5G entrer en vigueur au sein de la même année, comme le ferait la Chine.

Samsung a été un innovateur reconnu dans les technologies de transmission sans fil pendant une longue période, et ayant même déposer un certains nombres de brevets sur le terrain. La plupart d’entre eux sont considérés comme essentiels, nécessitant que Samsung accorde des licences équitablement et raisonnablement, et sans aucun degré de discrimination parmi ses concurrents.

En 2020, nous aurons des dizaines de nouveaux super-héros et de nouveaux films, de nouveaux Star Wars, et nous serons en mesure d’accrocher nos téléphones dans notre salle de bain. Nous sommes prêt pour disposer d’un réseau 5G ! Disons que nous pourrons utiliser ce réseau pour des occasions plus « réelles »…

Avant d’entrer dans les détails et tenter d’expliquer ce terme « 4G » parlons un peu d’Orange – oui quand même ils m’ont invité c’est normal. Après avoir ouvert le réseau 4G à Marseille en juin 2012, Lyon, Nantes et Lille en novembre 2012, Orange a décidé d’étendre son réseau dans dix nouvelles agglomérations le 4 avril dernier, dont La Rochelle donc ! Parmi les cinq agglomérations retenues par Orange – La Rochelle semble avoir été sélectionné pour son côté touristique – ce sont 50 villes qui sont désormais couvertes par la 4G d’Orange. Pour les petits malheureux, sachez qu’Orange a annoncé un nouveau déploiement dès juin 2013 ! Pour en bénéficier, sachez que l’opérateur propose jusqu’à différentes offres 4G dont la première – l’Origami Play 4G/H+ 2Go – est proposée à partir de 30,90 euros/mois ! À noter que jusqu’au 31 décembre 2013 et afin d’accompagner le déploiement de la 4G, pour 1€ de plus vous allez bénéficier de l’option multi-SIM afin de partager votre forfait internet mobile avec votre tablette, le cloud d’Orange – 100 Go – la TV d’Orange ou encore Deezer premium ! Autrement dit, cela s’avère très intéressant.

3G vs. 4G : Quelle est la différence ?

Pour le consommateur moyen, « 3G » et « 4G » sont deux termes les plus mystérieux dans le dictionnaire de la technologie mobile, mais ils sont utilisés sans relâche pour vendre des téléphones et des tablettes. Si vous êtes en train de lorgner pour un nouveau téléphone, le choix n’est pas évident, et il n’est pas certains que la meilleure solution soit de prendre le smartphone le plus cher. Quelle technologie choisir ?

Tout d’abord, le « G » correspond à une génération de la technologie mobile, installée dans les téléphones et les réseaux cellulaires. Chaque « G » nécessite généralement que vous allez devoir changer de smartphone, et pour les réseaux de faire des mises à niveau coûteuses. Les deux premiers étaient des téléphones cellulaires analogiques (1G) et les téléphones numériques (2G). Puis tout s’est compliqué…

Les réseaux mobiles de troisième génération, ou 3G, est arrivé vers 2003 – 2004. Avec des vitesses minimales cohérentes de 144 Kbps, ils étaient censés apporter le « débit haut mobile ». Cependant, il y a maintenant tellement de variétés de 3G, que d’une connexion « 3G », vous pouvez obtenir des vitesses allant de 400 Kbps à dix fois plus vite.

Les téléphones 4G sont censés être encore plus rapide, mais ce n’est pas toujours le cas. Il y a tellement de technologies dites « 4G », et tellement de façons de les mettre en œuvre, que le terme est presque vide de sens. L’International Telecommunications Union, un organisme de normalisation, a tenté d’édicter des prescriptions d’appeler un réseau 4G, mais ils ont été ignorés par les opérateurs, et finalement l’UIT a reculé. Les technologies 4G incluent HSPA+ 21/42, WiMAX, et LTE (bien que certains considèrent que la 4G LTE est la seule technologie importante).

Concernant la 4G d’Orange, la société précise qu’il s’agit du seul opérateur à proposer aujourd’hui des débits maximums théoriques allant jusqu’à 150 Mbit/s permettant ainsi de synchroniser ses playlists (50 Mo) Deezer en un instant – 8 secondes en 4G, 1 minute 20 pour la 3G. Idem pour le téléchargement d’une application de 25 Mo, Orange annonce une durée de 4 secondes avec la 4G contre 40 secondes en 3G.

Pour vous en convaincre voici un petit test :

Note : Je soupçonne un problème avec la 3G dans la boutique … et puis un Free Mobile dans une boutique Orange …

Note 2 : Oui oui Céline merci de ton intervention, Seb a raison je filmais

Quand choisir la 4G

Il faut donc se rendre à l’évidence, la 4G reste encore à l’heure actuelle très embryonnaire. Les opérateurs de téléphonie mobile sont encore en train de construire leurs réseaux 4G, donc d’abord, vous devez savoir si vous êtes éligible à une couverture 4G pour apprécier disposer d’un smartphone 4G. Bien sûr il n’y a pas que Orange qui offre une couverture 4G mais le géant opérateur fait parti des plus gros. Free Mobile aurait annoncé 373 nouvelles antennes, en expliquant qu’il créerait « quelque chose de nouveau, de révolutionnaire ». SFR a quant-à lui lancé fin janvier son réseau dans l’ouest Parisien, tant pour les entreprises que pour les particuliers – Paris devrait être intégralement couvert fin 2013. Bouygues Telecom proposera de son côté des offres à partir du 1er octobre.

Si vous aimez surfer sur le Web et en particulier consommer des flux vidéo, la 4G peut être le paradis. Si vous connectez un ordinateur portable à votre mobile, la 4G offre une énorme différence. En général, tout ce qui concerne le transfert de grandes quantités de données est bon à prendre avec la 4G. En revanche, il est nécessaire de faire attention à la limite de données imposée par l’offre à laquelle vous avez souscris, même si, car il est très facile d’utiliser un grand nombre de données rapidement avec la 4G.

Si vous avez un téléphone 3G et vous êtes frustrés du débit proposé, la 4G peut être la solution. Mais attention, la 4G ne va pas résoudre tous les problèmes d’appels, et ce puisque tous les appels seront effectués sur les réseaux 3G jusqu’à ce que les opérateurs passent la voix sur le réseau LTE au cours des prochaines années.

De plus, dans l’univers de la 4G vous devrez faire face à une couverture très limitée, et un choix restreint de smartphones… À l’heure actuelle, Orange propose une gamme d’une dizaine de smartphones compatibles, une tablette, et entend d’ici fin 2013, offrir la moitié de ces terminaux en 4G/H+.

Quand acheter 3G

Si vous voulez un iPhone, ça va être la 3G. Rien à ajouter. Apple pourrait sortir un iPhone 4G LTE plus tard cette année, mais la société ne dispose pas actuellement d’un modèle 4G. (Le « 4″ de l’iPhone 4 fait référence au numéro de modèle, pas à la technologie mobile.)

Si vous habitez dans une région qui n’a pas de couverture 4G, il n’y a aucun avantage à prendre un smartphone 4G. En fait, vous serez lésé puisque l’autonomie de votre smartphone s’en ressentira, et ce puisque la recherche d’un signal inexistant 4G peut causer quelques problèmes à l’autonomie .

J’espère que cela éclaircit le dilemme de la 3G versus la 4G. Si vous avez quelque chose à ajouter, n’hésitez pas à laisser un commentaire ci-dessous.

Quels sont les goulots d’étranglements possible ?

Avant de se dire que varnish est la solution au problème de montée en charge, il faut d’abord analyser où se situent les goulots d’étranglements. Pour ceux qui se posent la question, un goulot d’étranglement est simplement l’endroit où le bouchon se forme dans le réseau et donc où les données ne passent plus.

Les causes peuvent être diverses : réseau public Internet saturé,  un problème matériel, une application mal programmée consommant des ressources inutilement et enfin trop de connexions simultanées sur le serveur web ou sur le serveur MySQL.

Plus il y a de connexions et plus le serveur web doit générer de pages. Cette génération est coûteuse en terme de ressources.

Rôle de Varnish

Varnish est ce qu’on appelle un Reverse Proxy. Il est placé devant le serveur Apache et va pouvoir filtrer les requêtes arrivantes. Ce qui est important de retenir c’est qu’un serveur même petit est capable de délivrer une quantité très importantes de pages statiques. Ce qui est consommateur c’est la génération des pages dynamiques. Par son positionnement Varnish va agir comme un cache. Pour mieux comprendre, un petit schéma issu de Wikitwist

Le serveur Varnish peut être installé soit sur un autre serveur que l’Apache, soit sur le même.

Déroulement d’une mise en cache

• Le visiteur demande une page (ex : http://www.blog-nouvelles-technologies.fr/archives/15756/vous-avez-15-minutes-et-vous-voulez-apprendre-git/ )
• Varnish reçoit la demande
• Varnish regarde s’il possède cette page en cache. C’est la 1ere fois donc le cache n’existe pas
• Varnish fait suivre la demande à Apache qui fait son boulot et génère la page
• Apache renvoie le contenu a Varnish
• Varnish enregistre le contenu en cache
• Varnish renvoie le résultat au visiteur
• Un autre visiteur (ou le même) redemande la même page
• Varnish reçoit la demande et regarde dans son cache. Cette fois la page existe déjà
• Varnish renvoie directement le résultat

Apache n’a pas du tout connaissance de la demande qui vient d’être formulée

Mais ça fausse mes statistiques Analytics ce truc

Absolument pas. Analytics et autre tracker Javascript sont installés côté client. Ils sont donc exécutés à l’affichage du rendu HTML et seront toujours présents dans la page en cache

OK mais moi je gère une boutique et mon block panier ne doit jamais être statique

Effectivement c’est un problème. Il existe différentes solutions pour remédier à ce problème. Varnish réagit en fonction de règles définies. Par exemple on peut lui dire si la page se termine par .html (cas de réécriture d’URL) alors tu la mets en cache pour un jour. Par contre si l’URL est en .php|.jpg|.css  ou si je suis dans le dossier /admin alors tu passes toujours la main à Apache.

On peut également vérifier si un cookie existe. L’utilisateur a un cookie qui indique qu’il est administrateur par conséquent tu passes la main à Apache.

L’autre solution plus complexe permet de dire dans une page statique à 90% comme une fiche produit, j’ai besoin d’avoir qu’un petit block dynamique pour afficher mon panier. On utilise donc les ESI comme ceci dans le code source

<esi:include src="http://example.com/1.html" alt="http://bak.example.com/2.html" onerror="continue"/>

L’ESI permet de dire à Varnish, cette partie, tu la demandes à Apache même si tu as un cache.

Conclusion

Pour ceux qui désire le mettre en place, je vous conseille de suivre l’excellent tutoriel de nicolargo sur le couple Varnish + WordPress.

Vous verrez que le gain en terme de performances est vraiment impressionnant si votre site draine un trafic relativement important. Par exemple je l’ai mis en place pour un site qui faisait des pubs TV à des moments précis et qui voyait son serveur sauté à chaque fois. La simple installation sur le même serveur et surtout la bonne configuration de Varnish a suffit à absorber la montée en charge.

Alors convaincu ? Allez vous essayer de mettre ça en place sur votre serveur ?

Si vous avez déjà fait quelques recherches sur le Web, vous n’êtes pas sans savoir qu’il y a certes de nombreuses ressources, mais combien vous offre une liste complète couvrant l’ensemble des différents aspects qui doivent être pris en considération en vue de mettre en œuvre et de valider une migration de domaine d’un point de vue SEO ? Personnellement c’est rare…

Afin de vous aider dans ce processus quelque peu complexe, surtout quand vous savez par où commencer, Aleyda va vous y aider grâce à une infographie intitulée SEO Friendly Domain Migration. Celle-ci nous permet de compiler les différentes phases du processus de migration, allant de la prise de décision, de la planification, la mise en œuvre et le suivi. Ainsi, vous voici avec une check-list des opérations à faire, et les outils utilisés par Aleyda :

Note : Vous pouvez cliquer sur l’image ci-dessus pour avoir une version en grand format

Il s’agit d’une première série d’article basée sur la migration d’un nom de domaine, dans lequel je vais m’aventurer dans quelques temps…

Cette infographie vous a t-elle aidé ? Quels autres aspects prenez-vous en considération pour vous assurer que le SEO ne souffre pas d’une migration de domaine ?

C’est toujours flou pour vous ? Si c’est le cas, je vous propose de regarder la vidéo ci-dessous. Celle-ci a été réalisée en collaboration avec le CENTR et l’AFNIC.

Il s’agit d’une vidéo très ludique, qui peut s’avérer très pédagogique… Ainsi, vous allez pouvoir comprendre comment fonctionne le système d’adresse sur Internet, et ainsi établir une relation entre le nom de domaine, l’adresse IP et le DNS !

Pour résumer la vidéo, dès lors que vous êtes en réseau, autrement dit sur le Web, vous utilisez une adresse IP pour être localisé et ainsi vous connectez à d’autres dispositifs. Mais, il va être difficile de se rappeler de l’adresse IP d’une machine… Par exemple, sur le Web, c’est beaucoup plus facile de se souvenir du nom de domaine www.blognt.fr que de se souvenir de son adresse IP correspondante (178.33.204.24).
C’est là qu’intervient le DNS… Avec lui, vous allez pouvoir vous connecter à un autre ordinateur sur le réseau, ou un service distant en utilisant son nom de domaine, plutôt que son IP numérique…
À l’inverse, le Reverse DNS (rDNS) traduit une adresse IP en un nom de domaine.

Alors vous êtes désormais plus à l’aide avec le DNS ?

Comme son nom l’indique (ou pas), We Sun Solve s’adresse principalement aux administrateurs de machines Solaris. Pour ceux qui ne connaissent pas, c’est un système d’exploitation UNIX propriétaire développé à l’origine par Sun Microsystems, et racheté par Oracle en janvier 2010. Le nom désormais donné au système est : Oracle Solaris.

C’est précisément l’acquisition de Sun par Oracle qui a poussé l’auteur du site à se lancer, constatant l’abandon progressif de l’ancien site de support aux utilisateurs de Solaris bien connu : Sun Solve !

Ceux d’entre vous qui ont déjà administré des machines Sun s’en sont certainement rendu compte très vite : les mises à jour et correctifs sous Solaris sont souvent difficiles à gérer (de part leurs nombres, leurs classifications…). Et c’est à ce moment que Sun Solve était très utile. Il permettait aux administrateurs de s’y retrouver…

Mais heureusement, Thomas Gouverneur a reprit l’ancienne philosophie de SUN et d’Unix en général : KISS (Keep It Simple Stupid) !

Grâce à Sun Solve, vous pouviez avoir toutes les informations sur les correctifs à appliquer sur vos serveurs, les bugs qui étaient identifiés et en cours de résolution, quelles étaient les dépendances, etc… We Sun Solve reprend toutes ces possibilités et en rajoute bien d’autres : Flux RSS, recherche de bugs, détails des compilations de correctifs (patch clusters), analyse de l’état du patching de votre serveur, etc…

We Sun Solve va ainsi vous permettre de connaître les dernières informations du système d’exploitation.

Aujourd’hui, en même temps que la version 2.0 du site internet, vient s’ajouter une liste de nouvelles fonctionnalités à but « communautaire » ! Et oui même pour ces vieux systèmes il faut passer au « 2.0″ ! Vous aurez ainsi la possibilité de commenter (en privé ou en public), les différents bugs, patchs, bundles et autres éléments présents sur le site.

Au niveau technique, ce site utilise uniquement des logiciels libres, et parmi eux on peut citer les plus connus : Apache, MySQL, PHP5, Curl et Wget. Son fonctionnement est simple : dès lors qu’un correctif est publié, celui-ci est automatiquement téléchargé et les informations qu’il contient sont traitées et mises à disposition via une base de données.

Avec une base de données comptant désormais plus de 6 GBytes ainsi qu’un volume de patch indexés dépassant les 500 GBytes, il essaie donc de tenir la charge et espère pouvoir continuer longtemps à satisfaire ses utilisateurs, chaque jour plus nombreux. À l’heure actuelle We Sun Solve référence plus de 73 293 correctifs depuis 1990 et 359 998 bugs.

En bref, si vous administrez des machines Solaris je vous recommande fortement de rejoindre cette communauté !

Vous avez la possibilité de suivre We Sun Solve sur Twitter @wesunsolve.

Que pensez-vous de cette initiative ? Êtes-vous administrateur Solaris ? Le rachat de Solaris par Oracle vous a-t-il pénalisé ? Venez réagir…

Mon premier billet

A l’heure où nous parlons de plus en plus de protection des données et de la sphère privée sur Internet, des lectrices et lecteurs du blog nous ont demandé s’il nous était possible de réaliser un billet sur un acteur important de cette protection -ou plutôt devrais-je dire sécurisation- : le SSL.

Avant de continuer je tiens à vous préciser là qu’il s’agit de ma première contribution sur le Blog des Nouvelles Technologies mais également de mon premier billet sur un blog (et oui, comme quoi…). Mes capacités rédactionnelles n’étant pas mon principal atout je vous serais grès d’être indulgent –au moins le temps que je trouve mon style- je vous en remercie par avance.

De même, mes connaissances, informations et sources n’étant pas parfaite, il est possible que ce billet comporte des imperfections. Si tel est le cas je vous remercie de me le faire savoir en commentaire (sur le blog en fin de billet) afin que nous puissions les corriger.
Avant de détailler l’utilisation du SSL il me semble de bon goût de reprendre quelques bases, sans reprendre l’intégralité du fonctionnement d’internet hein, mais juste quelques notions pour que vous compreniez bien. C’est pour ça que j’ai préféré commencer par un article sur le protocole de communication¹ HTTP qui nous permettra par la suite, dans un autre billet relatif au SSL de parler entre autre du HTTP + SSL : le HTTPS.

Rassurez-vous, nous n’allons pas parler DNS, réseau ou autre… ce sera peut-être l’objet d’un futur billet… qui sais… pour le moment concentrons-nous sur ce fameux protocole que vous utilisez tous les jours… si si vous allez voir

Note : Bien que j’essaie de ne pas employer de terme technique sans les expliquer un minimum, il se peut que vous désiriez aller plus loin, vous trouverez alors des liens vers des articles de Wikipédia notamment, vous permettant d’en savoir plus à propos de certains termes utilisés que j’annote dans le texte.

Le protocole HTTP

Alors celui-là (le protocole HTTP) comme je viens de vous le dire, c’est surement celui que vous connaissez le plus, enfin, en tout cas que vous utilisez le plus. HTTP pour HyperText Transfer Protocol, en français « Protocole de Transfert HyperTexte ».
Lorsque vous parlez du Web, et bien vous parlez du protocole HTTP à l’échelle mondiale. En effet Internet regroupe de nombreux protocoles dont ce que nous nommons communément le Web. Pour information nous trouverons parmi les autres protocoles et usages : le FTP, la messagerie électronique, la messagerie instantanée (MSN, Jabber/XMPP…) et bien d’autres usages ou protocoles.

Il faut donc bien comprendre que le Web et Internet ne sont pas la même chose contrairement à ce que pense énormément de gens. Le Web (donc le protocole HTTP) utilise le réseau Internet comme il peut être sur un réseau privé non relié à Internet. De même, Internet est utilisé par beaucoup d’autres protocoles de communication autre que le HTTP.
HTTP n’est donc pas réservé à Internet, il est également utilisé sur des Intranet d’entreprise ou même sur des réseaux locaux de petites tailles (réseau au domicile de plus en plus courant).

Son rôle est de permettre le transfert de fichiers localisés grâce à une chaîne de caractères nommée URL entre un client et un serveur. Rien de bien compliqué, vous allez voir.

Ce protocole (HTTP) se positionne au niveau de la couche applicative et repose entre autre sur un autre protocole, le TCP (rapidement : il s’agit d’un protocole réseau qui s’ assure de la qualité de la transmission effectuée à l’inverse du protocole UDP pour lequel l’information est envoyée sans contrôle de ce qui est reçu… ou non).

Le HTTP côté client

Lorsque vous surfez sur le Web, vous utilisez un navigateur (Internet Explorer, Firefox, Safari, Chrome, Opéra…). Ce navigateur est en fait un client HTTP (la plupart des navigateurs supportent également d’autres protocoles tel que le FTP (File Transfer Protocol : Protocole de transfert de fichiers qui permet de transférer des fichiers d’un client à un serveur de manière multi-directionnelle) par exemple mais ce n’est pas l’objet de ce billet.

Donc… ne vous inquiétez pas avec l’habitude je devrais parvenir par moins m’égarer… ^^

De l’URL à la ligne de requête…

Donc je disais, le HTTP vous l’utilisez à chaque fois que vous surfez sur le Web. Tenez là par exemple, vous êtes sur Le BNT, dans la barre d’adresse vous avez d’indiqué une adresse similaire à cela :

Ça c’est ce que nous appelons une URL (Uniform Resource Locator, « localisateur uniforme de ressource ») ² plus souvent appelée à tort « adresse web » (je dis à tort car comme je vous l’ai expliqué le terme Web est l’utilisation faite du protocole HTTP et non d’Internet, or une URL peut être utilisée sur d’autre protocole comme nous allons le voir).

Sur certains navigateurs comme Chrome, le « http:// » n’est pas affiché car Chrome (et je crois que Firefox fera bientôt de même) considère que cette information peut ne pas être affichée en permanence pour l’utilisateur puisque… justement permanente. Nous allons y revenir.

Vous vous êtes déjà posé la question en fait de ce que cela signifie et de la manière dont votre navigateur interprète cette information ? Bon on va faire bref, c’est juste pour que vous suiviez bien jusqu’au bout.
On peux découper cela en 7 parties :

• http
• :
• //
• www.blog-nouvelles-technologies.fr.
• :
• 80
• /archives/5515/google-ouvre-un-projet-de-base-de-donnees-nosql-appele-leveldb/

Bon OK j’ai un peu triché parce que là j’en ai ajouté, mais vous allez voir c’est très simple et utile à savoir pour la suite :

• http on indique au navigateur le protocole souhaité. Si nous n’en indiquons pas, ce sera celui-là qui sera mis par défaut par le navigateur (on pourrait indiquer FTP si nous souhaitions utiliser le protocole FTP). C’est ce que je vous disais à l’instant, l’URL précise le protocole qui n’est pas obligatoirement du HTTP.
• : Il s’agit d’un caractère de séparation qui est obligatoire lorsque l’on précise le protocole à utiliser.
• // Chaîne de caractères permettant de préciser le service pour les protocoles dont la requête comprend un chemin d’accès
• www.blog-nouvelles-technologies.fr. le nom de domaine « pleinement qualifié », c’est-à-dire le site que vous souhaitez consulter (volontairement laissé en une seule partie ici car le but n’est pas d’expliquer le fonctionnement du DNS). Vous avez vu à la fin j’ai mis un point « . » ne pensez pas qu’il s’agit d’une faute, c’est volontaire OK c’est du DNS mais à décortiquer l’adresse on va brièvement s’arrêter dessus. C’est ce qu’on appelle la terminaison DNS, en d’autres termes on indique au navigateur qu’il ne doit rien ajouter après le nom (il ne doit donc pas ajouter le domaine dans lequel nous nous trouvons). Cela lui indique que l’adresse indiquée est un FQDN (Full Qualified Domain Name : Nom de domaine pleinement qualifié, en clair « le domaine est complet donc t’es gentil petit ordinateur, tu rajoute rien après »). Bon vu que ce serait assez lourd de devoir à chaque fois ajouter un point après l’adresse, votre gentil navigateur le fait pour vous (sympa le type).
• : caractère de séparation permettant d’indiquer que nous allons préciser le port à utiliser
• 80 çà c’est le port³. Bon là aussi on va pas expliquer ce qu’est un port mais si on schématise très grossièrement, un ordinateur à plein de ports (comme un bâtiment a de nombreuses fenêtres) et chaque application devant être délivrée sur un serveur va monopoliser un ou plusieurs ports (un peu comme si chaque employé avait sa fenêtre de bureau de manière propre et indivisible). Sur un serveur on trouve 65536 ports et ce qu’il faut savoir c’est que tous les ports de 1 à 1024 sont réservés donc « pas touche, c’est réservé ! ». Notre serveur Web lui écoute par défaut sur le port 80 (il peut écouter sur n’importe lequel, c’est au choix de l’administrateur mais c’est quand même vachement bien de respecter les standard hein… et puis surtout vous allez pas vous amusez à chercher sur quel port le serveur du BNT va répondre à votre requête HTTP….) donc sauf cas particulier et justifié (au goût de l’administrateur) il sera toujours sur le 80. Comme expliqué c’est un standard donc là aussi votre gentil petit navigateur (même IE, si si je vous jure) va vous mâcher le travail : si vous ne mettez rien, il le rajoute
• /archives/5515/google-ouvre-un-projet-de-base-de-donnees-nosql-appele-leveldb/ là on sort du sujet, il s’agit du positionnement du fichier que nous souhaitons consulter sur le serveur. Dans le cas du BNT il est fait utilisation d’URL Rewriting⁴ (réécriture d’URL). Nous pourrons là aussi en reparler dans un futur sujet. En attendant retenez juste que cela permet au serveur de savoir quelle ressource vous souhaitez visualisez sur le site du BNT. A noter que ce chemin pourrait également par la suite contenir des données supplémentaires transmises en GET. Hein, en quoi ? Ne vous inquiétez pas, nous y reviendrons après.

Donc au final et bien notre URL elle donne ça :

http://www.blog-nouvelles-technologies.fr.:80/archives/5515/google-ouvre-un-projet-de-base-de-donnees-nosql-appele-leveldb/

N’hésitez pas à cliquer dessus, vous constaterez que cela fonctionne parfaitement avec le .:80 (et heureusement d’ailleurs…. Le navigateur devrait masquer le port et laisser le point final).

Bon j’espère que vous comprenez déjà un peu mieux ce qu’il se passe quand vous tapez une adresse dans votre navigateur d’un point de vue HTTP (on n’aborde pas la partie réseau, DNS ou autre comme dis en début de billet).

Ça c’est pour ce que vous voyez dans votre navigateur. Comme je vous l’ai montré, bien que certains éléments de l’URL ne soient généralement pas affichés, vous pouvez si cela vous en dit les taper et cela fonctionne.
Et bien tout cela c’est ce que l’on appelle la ligne de requête.

Lorsque vous demandez à votre navigateur d’aller récupérer cette page, il va donc contacter un serveur et va récupérer le contenu.

Comment ? Nous y arrivons.

Les en-tête HTTP de requête et le corps de requête

Votre navigateur transmet votre ligne de requête en effectuant ce que l’on appelle la commande GET. Il existe plusieurs types de commandes, nous les verrons après.
Mais il y a également d’autres données qui sont transmises au serveur par votre navigateur et que vous ne voyez pas du tout.

En effet, lorsque vous validez cette ligne de requête, votre navigateur va se connecter au serveur puis, une fois la connexion établie va lui envoyer d’autres informations :

• Les champs d’en tête de la requête : facultatif, mais on peut dire qu’ils sont toujours envoyés. Il s’agit en fait d’un ensemble de lignes permettant de transmettre des informations au serveur comme par exemple le navigateur utilisé ou le système d’exploitation… Ces lignes sont formatées de la même manière : nom du type d’en-tête : valeur de l’en-tête. On appelle cela de la négociation de contenu⁵. Quelques exemples :

User-Agent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Accept : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language : fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Charset : ISO-8859-1,utf-8;q=0.7,*;q=0.7

• Le corps de la requête : il s’agit là aussi d’un ensemble de ligne non obligatoire que l’on sépare des lignes précédente (en-tête) par une ligne vide. Cela permet par exemple l’envoi de données via la commande POST comme lorsque vous validez un formulaire.

Ainsi, les champs d’en-têtes permettront par exemple au serveur distant d’envoyer le document dans la langue souhaitée par le client… si celle-ci est disponible.
Vous pouvez la trouver en bas de page un lien vers une liste complète des en-têtes existantes ⁶.
A l’aide d’un petit outil sur mon navigateur (Firefox) je peux voir ce qu’il se passe au cours de ces échanges. Cet outil se nomme HTTPFox. Ainsi, si j’accède par exemple au site www.web4all.fr

Comme vous pouvez le voir sur cette copie d’écran, nous avons en haut les différentes requêtes envoyées au serveur, la première ligne étant celle envoyée en premier lorsque j’ai appelé le site www.web4all.fr.

En cliquant dessus, j’obtiens dans la partie inférieure le détail des données. L’onglet sélectionné Headers me permet de voir les en-têtes envoyées, on y retrouve bien les exemples que je vous donnais tout à l’heure.

Et si j’avais envoyé des données vers le serveur, comment cela se serait-il passé ?

Les méthodes GET et POST

Pour envoyer des données vers le serveur nous avons deux solutions :

• En utilisant la méthode GET : c’est comme pour le reste de l’URL, on ajoute à la fin de l’URL les paramètres que nous souhaitons envoyer. Cela se fait ainsi : un point d’interrogation pour indiquer que nous allons envoyer des données supplémentaires et les données : nom de la données = valeur de la donnée ce qui nous donne donc : ?user=starchou (où starchou est mon pseudo). Cela nous donnerait par exemple sur une URL : http://www.web4all.fr/index.php?user=starchou Ainsi, je suis capable dans le script côté serveur de récupérer la valeur de user soit : starchou
• En utilisant la méthode POST : là c’est plus intéressant, cela ne se voit pas dans l’URL mais cela ne veut pas dire que c’est invisible. Et encore moins que cela est sécurisé ! Le principe est le même que le précédent mais la donnée ne peut-être ajouté par vous-même dans l’URL, c’est le concepteur de la page sur le serveur qui va créer des champs (que vous remplissez) et qui seront transmises en POST (car le développeur l’a explicitement indiqué lors de la création de son formulaire).

Je le redis, ce n’est pas parce que l’on ne voit pas les données que cela ajoute de la sécurité, cela n’est absolument pas plus sécurisé que la méthode GET. Et un utilisateur peut très facilement envoyer des données s’il le souhaite même si cela n’est pas prévu dans la page.
Ainsi, si l’on reprend HTTPFox, et que nous regardons ce qu’il se passe sur la validation d’un formulaire utilisant la méthode POST, voilà ce que nous voyons :

Alors là, nous avons plusieurs informations :

• auth_key ———————————–
• referer http://forums.web4all.fr/index.php?
• username Starchou
• password ——–
• rememberMe 1

La première et la seconde ligne sont sans importance pour notre exemple.
De la troisième à la cinquième ligne en revanche, nous avons toutes les informations du formulaire : le nom d’utilisateur, le rememberMe car j’ai coché la case « Se souvenir de moi » mais surtout : le mot de passe. Oui, vous avez bien lu, ce champ contient mon mot de passe, en « clair », que n’importe qui peut lire en arrivant à attraper le flux entre mon ordinateur et le serveur que je contact.
« Hein ? C’est quoi ce bordel là ? N’importe qui peut lire ce que j’envoie sur les sites que je consulte !?»

Et bien désolé de vous décevoir si vous pensiez le contraire mais OUI ces données sont « publiques » si je puis dire (du moins elles le sont de fait).

Et c’est là qu’on arrive ENFIN à parler d’une chose… le HTTPS. Il s’agit tout simplement du protocole HTTP, celui que nous venons de voir mais avec un détail en plus, le S. Ce S il signifie Secured (Sécurisé) et nous l’obtenons grâce à l’utilisation du fameux protocole SSL (Secured Sockets Layer) ou plutôt devrais-je dire TLS (Transport Layer Security) qui est sa nouvelle dénomination… depuis 2001.
Il s’agit en fait d’un protocole de sécurisation des échanges de données et je n’en dirais pas plus car comme je vous l’expliquais en tout début d’article ce sera l’objet du billet suivant. Retenez juste une chose en attendant le billet sur SSL/TLS : n’envoyez jamais d’informations sensibles si le protocole utilisé est HTTP et non HTTPS ! Ça, c’est dit, maintenant on passe à la suite.

Hé, ho, ce n’est pas parce que vous êtes arrivé au mot SSL qu’il faut arrêter de lire l’article et se dire que vous allez attendre le billet sur le SSL/TLS. Vous avez commencé alors maintenant il faut aller jusqu’au bout. Allez rassurez-vous le plus dur est passé.

A propos de la méthode POST, je suis sûr que vous avez déjà été confronté à cela :

En fait cela se produit lorsque vous validez un formulaire qui va envoyer des informations en utilisant donc la méthode POST. Mais à ce moment-là pour une raison qui vous est propre vous actualisez la page quelques temps après. Et la PAF, votre navigateur vous sort cet infâme message auquel vous n’avez jamais très bien compris en quoi cela consistait techniquement parlant.

Et bien c’est très simple, en actualisant la page vous renvoyez au serveur la même requête que précédemment, et donc vous renvoyez à nouveau les données POST. Pas très grave sur un simple formulaire d’identification, mais peut être plus gênant si vous venez de vous inscrire par exemple sur un site. Là pas de chance, le développeur (Kevin) a mal fait son travail et soit vous avez un message d’erreur comme quoi l’utilisateur existe déjà soit… le dev a vraiment mal fait son travail et devrait penser à se reconvertir (j’en connais…) et cela vous créée un deuxième compte (à la limite c’est plus gênant pour le gestionnaire du site que pour vous dans ce cas-là hein…).

C’est pour cela qu’en général, une fois les données du formulaire récupérées par le serveur et traitées, le développeur aura pris soin de faire en sorte que vous soyez redirigé vers une page afin de vider ces informations POST sans que vous n’ayez pas le temps de le voir (si les choses sont bien faites).
Voilà, nous venons de voir le côté client (votre navigateur), nous allons maintenant voir le côté serveur.

Le HTTP côté serveur

Le serveur (je parle ici du serveur logiciel : le serveur Web et non du serveur au sens matériel : la machine) est là pour publier du contenu. En résumé, son travail est simple, un client le contact, il traite la demande et s’il le peut, il répond en délivrant la ressource demandée. Bien entendu, dans la pratique le serveur Web se verra greffer de nombreux rôles supplémentaires à l’aide de modules lui permettant ainsi de traiter différents langages (Perl, Python, Ruby et bien sûr le Php… et bien d’autres) mais également lui permettre d’agir différemment à l’aide du mode Proxy (permettant de jouer un rôle de mandataire), du mode CGI (Interface de communication avec des serveurs applicatifs externes)…
Nous pourrons éventuellement, encore une fois traiter de cela dans de futurs billets mais pour le moment concentrons-nous sur son rôle principal.

Ce serveur il y a 64.88% de chance que ce soit un serveur Apache (serveur Web open-source). Et si ce n’est pas le cas, il reste 16.82% de chance alors que ce soit un serveur IIS (serveur Web commercialisé par Microsoft).

Enfin pour finir il restera 6.55% de « parts de marchés » pour Nginx et 4.61% de parts pour Google (qui a son propre serveur Web). Les derniers pourcents restants se retrouvent occupés par des serveurs récents encore peu connus qui se feront peut-être leur place petit à petit.⁷
Retrouvez une infographie détaillée traitant partiellement de ce sujet : http://www.blog-nouvelles-technologies.fr/archives/5122/infographie-et-si-lopen-source-venait-envahir-le-web/
Ce serveur donc, lorsqu’il va être contacté par le client (votre navigateur) va décoder la demande et vérifier s’il peut la traiter. Si ce n’est pas le cas vous obtiendrez un message d’erreur.

En effet le serveur lorsqu’il va répondre au client va lui transmettre une ligne de statut qui comportera :

• la version du protocole utilisée (HTTP/1.1 par exemple)
• le code de statut
• la signification du code

Le code de statut, appelé aussi code retour permet au navigateur de savoir si sa demande a été traitée ou non. Ces codes retour sont normalisés (spécifiés par la RFC 2616 http://tools.ietf.org/html/rfc2616 ) et on y trouvera notamment :

• 200 : OK (Ce qui signifie… que la demande est traitable sans problème)
• 301 : Moved Permanently (Document déplacé de façon permanente)
• 302 : Found (Document déplacé de façon temporaire)
• 403 : Forbidden (L’authentification est refusée. Contrairement à l’erreur 401, aucune demande d’authentification ne sera faite)
• 404 : Not Found (Document non trouvé)
• 500 : Internal Server Error (Erreur interne du serveur)

Et beaucoup d’autres codes…⁸
D’ailleurs si l’on reprend notre requête envoyée tout à l’heure au serveur nous constatons bien que ce dernier nous renvoi à chaque fois un code retour :

Ici nous avons bien un code 200 informant que la demande a été traitée avec succès.

Ensuite le serveur va renvoyer les champs d’en-têtes de la réponse, sur le même principe que nos en-têtes lors de la demande : nom du type d’en-tête : valeur de l’en-tête
Pour finir le serveur nous renverra bien heureusement (parce ce que c’est quand même cela que l’on souhaite à la base !) le corps de la réponse qui contient le document demandé.

Ah oui, j’allais oublier, comme je vous parle depuis tout à l’heure de GET et POST et que je vous ai promis à plusieurs reprises d’y revenir dessus, on va expliquer un peu ces fameuses commandes.

Il existe cinq types de commandes :

• GET: la commande que nous avons vu au début : lorsque nous envoyons la requête afin de récupérer ce à quoi elle correspond (d’où le GET car on récupère le contenu)
• HEAD: Ce sont nos fameux en-têtes que nous envoyons au serveur juste après le GET
• POST: la commande que nous avons vu lorsque nous validons un formulaire, permettant ainsi d’envoyer des données au serveur afin que ce dernier les traites.
• PUT: permet d’envoyer des données au serveur. Il ne s’agit pas d’envoyer des données comme en POST pour traitement par le programme mais plutôt de l’envoi par exemple d’un fichier.
• DELETE: permet de supprimer le fichier spécifié

Maintenant, nous avons vu ce qu’il se passait côté client et côté serveur. Si nous voulions résumer le tout, vous allez voir c’est très simple :

Nous avons bien un navigateur sur lequel un utilisateur demande une URL, une fois cette demande envoyée, elle est formatée par le navigateur qui y ajoute les en-têtes et le tout est envoyé au serveur.

Le serveur analyse la demande, s’assure de pouvoir la réaliser (il va par exemple vérifier que les fichiers sont bien présent, si ce n’est pas le cas il renverra une erreur 404) et formater sa réponse.

Pour finir le serveur envoi la ligne de statut, les en-têtes HTTP de réponse ainsi que le contenu demandé.

Un dernier point : votre navigateur vous présente les données après les avoir traités.
Si une erreur apparait dans ce processus, nous l’avons vu tout à l’heure, il existe une multitude de code retour qui permettra à votre navigateur de vous afficher le plus précisément possible le type d’erreur.
Dites-vous bien que lorsque vous consultez un site cette opération est réalisée des dizaines de fois. En effet il va falloir charger une multitude de fichiers : fichiers html, css, images… Vous verrez dans l’historique que je vous parle à un moment du transfert en Pipeline qui permet une accélération conséquente des temps de chargement, vous comprenez pourquoi cette évolution était bien nécessaire, surtout lorsque l’on prends en compte l’augmentation des données publiées sur les pages.
Note : il est interdit de se moquer de mon magnifique schéma.

Un peu d’histoire

Initialement cette partie était positionnée en début d’article, ce qui pourrait sembler plus logique et vous faire, sur ce coup, vraiment douter de mes capacités rédactionnelles ! Alors je tiens à préciser qu’il s’agit d’une volonté de ma part de positionner cela après les explications que je viens de faire. La raison en est simple, en me relisant je me suis dit que vous risquiez de ne pas beaucoup comprendre cette partie vu que la plupart des termes sont expliqués dans le reste de l’article.
C’est pourquoi nous allons aborder l’histoire du protocole HTTP maintenant, que vous êtes en mesure de comprendre sans aucun soucis –je l’espère- ce qui suis.

Ce protocole a été inventé en 1990 par notre cher Tim Berners-Lee (http://fr.wikipedia.org/wiki/Tim_Berners-Lee) dans une version que l’on nomme aujourd’hui HTTP/0.9 (qui n’est plus utilisée ou alors très peu).
S’en est suivi la version 1.0 en 1996, première à être décrite dans une RFC1945 (http://tools.ietf.org/html/rfc1945) permettant de nombreuses avancées telles que :

• la gestion de serveurs virtuels « Virtual Hosts » qui permet de mettre plusieurs domaines sur une même adresse IP et aujourd’hui croyez-moi nous sommes tous bien content que cela soit possible car vous n’êtes pas sans savoir que ces fameuses adresses IP dans leur formes actuelle (IPv4) sont en pénuries. Grâce à ce module on peut héberger des sites ayant différents noms sur une même adresse IP.
• la gestion de cache permettant d’accélérer les échanges et traitement
• la gestion de l’identification au niveau du serveur Web
• l’envoie de données d’en-tête comme vu au cours de l’article

Puis, nous arrivons en 1999… voilà HTTP/1.1 dans la RFC2616 ( http://tools.ietf.org/html/rfc2616 ). Cette version ajoute le support du transfert en pipeline permettant de combiner plusieurs requêtes HTTP dans une seule et même connexion TCP sans attendre les réponses correspondant à chaque requête permettant ainsi un gain considérable du temps de chargement d’une page. Cette version apporte aussi la négociation de type de contenu (format de données, langue) via encore une fois nos fameuses en-tête.

Conclusion

Si vous êtes arrivé jusqu’à la fin je ne peux que vous en remercier, j’espère que vous avez bien pu comprendre l’ensemble de l’article et que sa structure vous a convenu.

N’hésitez pas à me faire part de vos remarques avant que je ne me lance dans la rédaction des futurs billets, que je puisse en tenir compte. Et surtout n’hésitez surtout pas à poser vos questions, je me ferais un plaisir –dans la limite de mes connaissances et de ce que je pourrais trouver au besoin- de vous y répondre.

Le prochain article traitera, vous l’aurez compris de la sécurisation des échanges entre le client (votre navigateur) et le serveur à l’aide du protocole TLS (plus connu sous son ancien nom SSL).

Nous traiterons des généralités : présentation et explications. Puis des cas d’utilisation possibles (obligatoire, conseillé, sans intérêt), le cas des plate-forme de paiement en ligne. Enfin nous verrons ensemble comment mettre cela en place que ce soit chez un hébergeur mutualisé ou sur un serveur dédié / privé. Le sujet abordera donc un peu plus la technique mais je ferais en sorte qu’il reste accessible au plus grand nombre.

Si vous avez aimé l’article, n’hésitez pas à utiliser le bouton +1, à le partager sur les différents réseaux sociaux, cela afin de contribuer à la promotion du Blog des Nouvelles Technologies. Merci

Pour aller plus loin : les références

Tout d’abord, je vous invite à consulter l’infographie commenté par Yohann au sujet des en-tête de réponse HTTP : http://fr.wikipedia.org/wiki/Web

¹ Qu’es ce qu’un protocole de communication ? http://fr.wikipedia.org/wiki/Protocole_de_communication

² Qu’es ce qu’une URL ? http://fr.wikipedia.org/wiki/Rep%C3%A8re_uniforme_de_ressource

³ Qu’es ce qu’un port ? http://fr.wikipedia.org/wiki/Port_%28logiciel%29

⁴ URL rewriting – ré écriture d’URL : http://fr.wikipedia.org/wiki/.htaccess

⁵ Négociation de contenu : http://fr.wikipedia.org/wiki/N%C3%A9gociation_de_contenu

⁶ Article sur le protocole HTTP comportant un tableau récapitulatif des en-têtes existantes : http://www.journaldunet.com/developpeur/outils/part-de-marche-des-serveurs-web/

⁸ Liste des codes statut (code retour) HTTP : http://fr.wikipedia.org/wiki/Pipelining_http

Je dois également vous dire que je me suis appuyé sur des supports de cours obtenus lors de formations Apache, je ne peux malheureusement diffuser ces supports mais ai essayé de vous faire une synthèse de toutes ces sources de manière la plus compréhensible possible pour les non experts.

Dans cet article, je vais aborder la partie technique du protocole. Pour cela, nous allons analyser le modèle de traitement SOAP, le format du message, la procédure de l’appel à distance, et enfin l’enveloppe SOAP.

Modèle de traitement SOAP

Un message SOAP peut être véhiculé par plusieurs protocoles de transport comme illustrés dans la figure ci-dessous.

Le modèle de traitement SOAP décrit un modèle de traitement distribué, les participants, les nœuds SOAP et la manière dont un récepteur traite un message SOAP. Les nœuds SOAP suivants sont définis :

Émetteur SOAP (SOAP sender)

Un émetteur SOAP est un nœud qui envoie le message SOAP.

Récepteur SOAP (SOAP receiver)

Un récepteur SOAP est un nœud qui reçoit le message SOAP.

Parcours du message SOAP (SOAP message path)

Afin d’obtenir le nœud de destination, le message SOAP doit progresser à travers les différents nœuds. Le parcours que suit un message SOAP vers le récepteur est appelé parcours du message SOAP (SOAP message path).

Initiateur de l’émetteur SOAP (Initial SOAP sender)

Le nœud qui crée un message SOAP au début du parcours est appelé initiateur émetteur SOAP (Initial SOAP sender) .

Intermédiaire SOAP (SOAP intermediary)

Un intermédiaire SOAP est à la fois un récepteur SOAP et un émetteur SOAP et ciblé à partir d’un message SOAP. Il traite les blocs d’en-tête SOAP ciblés et agit en amont d’un message SOAP vers un récepteur SOAP final.

Récepteur SOAP final (Ultimate SOAP receiver)

Le récepteur SOAP est la destination finale d’un message SOAP. Il est responsable du traitement du contenu du corps SOAP et de tous les blocs d’en-tête SOAP ciblés. Dans certains cas, un message SOAP peut ne pas parvenir au récepteur SOAP final, par exemple en raison d’un problème sur un intermédiaire SOAP. Le récepteur ne peut pas aussi être un intermédiaire SOAP pour le même message SOAP.

Format du message

La partie principale de ce message a un type MIME text/xml et contient l’enveloppe SOAP. Cette enveloppe est un document XML. L’enveloppe contient un entête (facultatif) et le corps (obligatoire).
La partie du corps de l’enveloppe est toujours prévue pour le destinataire final du message, tandis que les blocs d’entête peuvent cibler les intermédiaires qui effectuent le traitement de l’acheminement du message. Les pièces jointes, binaires ou autres, peuvent être ajoutées à l’enveloppe.

Les en-têtes envoyés en complément du contenu principal du message SOAP, sont utiles dans l’ajout d’informations au message qui n’affectent pas le traitement du corps du message. Les en-têtes, par exemple, peuvent être utilisés pour fournir des signatures numériques pour une demande contenue dans le corps. Dans ce cas, un serveur indépendant d’authentification ou d’autorisation pourrait extraire la donnée de l’entête pour valider la signature. Une fois validé, le reste de l’enveloppe pourrait être répercuté sur le serveur SOAP, ce qui permettrait de traiter le corps du message. Un examen plus poussé de l’enveloppe SOAP aidera à clarifier la mise en place et le but de l’en-tête SOAP et les éléments du corps.

Appel de la méthode distante SOAP

Les messages SOAP sont des transmissions fondamentalement à sens unique d’un émetteur à un récepteur, mais ils sont souvent combinés pour mettre en œuvre des mécanismes de demande/réponse. Pour faire du RPC en utilisant SOAP, quelques conventions doivent être respectées. Tout d’abord, la demande des messages de réponse doit être codée comme des structures. Pour chaque paramètre d’entrée d’une opération, il doit y avoir un élément avec le même nom que le paramètre, et pour chaque paramètre de sortie, il doit y avoir un élément avec un nom correspondant. La demande invoque la méthode additionCalcul. Remarquez que la réponse définit une opération additionCalculResponse. Une convention commune à des appels SOAP pour ajouter la réponse à la fin d’une demande, afin de créer une structure de réponse.
Cette structure de sortie contient un élément appelé result, qui renvoie le résultat de l’appel de la méthode.

Bloc d’entête, de corps

Bloc <SOAP-ENV:Header>

SOAP définit des attributs optionnels applicables sur les éléments fils directs du bloc Header. Ces attributs sont:

• actor : cet attribut identifie le destinataire de l’élément fils. En effet, comme on l’a vu précédemment, un message SOAP peut traverser plusieurs composants avant d’atteindre le destinataire final du message. Il peut être nécessaire d’adresser des informations aux composants intermédiaires qui composent le chemin vers le destinataire final. C’est par l’intermédiaire de cet attribut que cela est rendu possible, en lui donnant comme valeur une URL qui correspond à ou aux destinataires de l’élément.
  Note : En l’absence de cet attribut, l’élément fils est à destination du destinataire final du message SOAP.
• mustUnderstand : cet attribut indique si le destinataire de l’élément doit absolument comprendre l’élément ou non. Si cet attribut est à 1, alors le destinataire doit absolument comprendre l’élément. Si ça n’est pas le cas, un message d’erreur (par ex., contenant un bloc Fault) est retourné.
  Note : Si cet attribut est à 0, l’élément peut être ignoré. C’est le comportement par défaut quand l’attribut n’est pas spécifié.
• encodingStyle : la signification de cet attribut est la même que pour le bloc Envelope. Sa portée reste cependant limitée à l’élément fils.

Voici un exemple du bloc Header :

<soap:Header>
  <m:Utilisateur xmlns:m="http://www.exemple.com/utilisateur/" soap:actor="http://www.exemple.com/utilisateur/User"> Yohann </m:Utilisateur>

  <m:Session xmlns:m="http://www.exemple.com/session/" soap:mustUnderstand="1">ABC123</m:Session>
</soap:Header>

Ici, on voit que l’élément Utilisateur est à destination du composant User et qu’il contient un nom d’utilisateur (Yohann).
L’élément suivant, Session, est à destination du destinataire final du message SOAP. Il indique un numéro de session (ABC123), et doit absolument être compris par le destinataire pour pouvoir traiter le message.

Bloc <SOAP-ENV:Body>

Ce bloc contient le corps du message, sa signification est spécifique à l’application.

Voici un exemple du bloc :

<!-- Exemple de requête -->
<SOAP-ENV:Body>
  <ns1:additionCalcul>
    <operation xsi:type="xsd:string">add</operation>
    <entier1 xsi:type="xsd:int">3</entier1>
    <entier2 xsi:type="xsd:int">4</entier2>
  </ns1:additionCalcul>
</SOAP-ENV:Body>

<!-- Exemple de réponse -->
<SOAP-ENV:Body>
  <ns1:additionCalculResponse>
    <result xsi:type="xsd:string">7</result>
  </ns1:additionCalculResponse>
</SOAP-ENV:Body>

Un prochain article nous permettra de mettre en application ce que nous venons d’étudier sur le protocole SOAP. Ainsi, nous écrirons un simple service Web permettant d’additionner / soustraire deux entiers.

N’hésitez pas à me partager vos remarques sur cet article.

Il utilise des technologies XML pour définir un cadre extensible de messagerie fournissant une construction de messages qui peuvent être échangés à l’aide d’une variété de protocoles sous-jacents.

Plus généralement, SOAP permet à des objets (d’un code source) de toute nature – sur n’importe quelle plateforme, dans n’importe quel langage – de communiquer. À l’heure actuelle, SOAP a été mis en œuvre dans plus de 60 langages sur plus de 20 plateformes.

Le cadre a été conçu pour être indépendant de tout modèle de programmation de sémantique mis en œuvre de manière spécifique. Il est important pour le développement des applications de permettre une communication Internet entre les programmes.

Aujourd’hui, les applications communiquent en utilisant le protocole Remote Procedure Calls (RPC) entre les objets comme DCOM et CORBA. RPC représente certes une compatibilité mais pose des problèmes de sécurité : les firewalls et les serveurs proxy bloqueront normalement ce genre de trafic. Une meilleure façon de communiquer entre les applications est d’utiliser le protocole HTTP, car ce dernier est supporté par tous les navigateurs Internet et les serveurs. SOAP a été créé à cette fin, à partir de 1998, pour fournir un moyen de communiquer entre les applications s’exécutant sur des systèmes d’exploitation différents, avec différentes technologies et des langages de programmation.

Les principes de SOAP

Les deux buts de conception majeur de SOAP sont : la simplicité et l’extensibilité. Un message SOAP peut être envoyé à un site web, par exemple par un service Web, pour obtenir le prix de l’immobilier enregistré dans une base de données, avec les paramètres nécessaires à une recherche.

Le site renverrait alors en retour un document au format XML avec les données obtenues, par exemple, le prix, l’emplacement et les caractéristiques. Parce que les données sont retournées sous un format normalisé et grâce à la souplesse du langage XML qui permet un nommage proche des fonctionnalités métiers, la lecture du message SOAP est relativement aisée par un humain, permettant ainsi d’être intégrée directement dans un site Web ou dans une application tiers.

Ce protocole applicatif peut s’appuyer sur différents protocoles de transport pour des échanges synchrones ou asynchrones :

• HTTP : échanges synchrones
• Java RMI : échanges synchrones
• SMTP : échanges aynchrones
• FTP : échanges aynchrones
• etc…

L’architecture SOAP se compose de plusieurs couches de spécifications. Par exemple, pour le format de message, il est possible d’avoir une séquence d’échange de messages (MEP) – Message Exchange Patterns – qui est un squelette établissant une forme de base pour échanger des messages entre nœuds SOAP, traitant les modèles des messages, et l’extensibilité du protocole.

Par ailleurs, SOAP désigne les informations échangées dans une syntaxe correspondant aux fonctions applicatives, contrairement à XML-RPC qui utilise uniquement des nommages techniques et primitifs. De plus, SOAP permet la sérialisation/désérialisation de tout objet métier, sous une forme XML utilisable quelle que soit la technologie d’implémentation. Enfin SOAP normalise la gestion des erreurs.

Fonctionnement de SOAP

Les données utiles de SOAP sont encapsulées dans l’enveloppe SOAP (qui elle-même fait partie des données utiles d’HTTP, supposant que vous utilisez HTTP comme protocole de transport). L’enveloppe SOAP, à son tour, se compose d’un en-tête SOAP (Header) et du corps (Body). Le prologue XML peut être présent, mais dans ce cas, ne doit contenir qu’une déclaration XML (c’est-à-dire qu’il ne doit contenir ni référence à un DTD, ni instruction XML). Le message doit utiliser l’enveloppe SOAP et les namespaces d’encodage SOAP, et doit avoir la forme suivante :

• Une déclaration XML (optionnelle)
• une Enveloppe SOAP (l’élément racine) qui est composée de :
  • Une En-tête SOAP (optionnel)
  • Un Corps SOAP

Le prologue XML contient seulement une déclaration XML <?xml version="1.0" encoding="UTF-8" ?> spécifiant la version de XML et l’encodage des caractères du message XML.

Le tag de l’enveloppe SOAP (<soap:Envelope xmlns:soap:"http://schemas.xmlsoap.org/soap/envelope/">) dans le message de requête, optionnel, spécifie tout d’abord que le style d’encodage de ce message SOAP suit le schéma défini dans http://schemas.xmlsoap.org/soap/encoding/. L’Enveloppe SOAP contient également des définitions de namespaces. Les identifiants des namespaces sont standards et la spécification SOAP demande à ce que ces namespaces soient définis correctement ou pas du tout.

La partie Header (<soap:Header>), facultative, porte des informations complémentaires pour le traitement des données (identification de l’émetteur du message, règles de sécurité pour la lecture du message, algorithme de chiffrement à utiliser pour la lecture du message, etc.) Il est important de rappeler que l’authentification et la gestion de session sont en dehors du cadre du protocole SOAP, même si SOAP autorise une certaine flexibilité dans la transmission des messages, de telle façon que les personnes qui les implémentent puissent inclure de telles informations.

La partie Body (<soap:Body>), porte les données propres du message, et matérialise la requête ou la réponse SOAP (structure de données spécifique). Les données sont sérialisées en XML en utilisant une combinaison d’éléments et d’attributs XML. La partie encapsule un unique tag de méthode qui porte le nom de la méthode elle-même <ns1:maMethode ... > (ou, le même nom suivi du mot « Response » dans le cas du message de réponse). Notez que le tag de la méthode reçoit typiquement le namespace correspondant au nom du service, pour assurer l’unicité (un service web, qui peut contenir n’importe quel nombre de méthodes nommées différemment, a un nom de service unique à l’URL sur lequel il est accessible.

Le tag de méthode encapsule à son tour un certain nombre de paramètres, tel que le tag <param1 ... > dans l’enveloppe d’une requête et dans le message de réponse, on ne trouve qu’un seul tag de paramètre représentant la valeur de retour de la méthode (généralement appelé <return>).

SOAP utilise couramment le protocole HTTP et est donc très évolutif dans sa forme native. C’est probablement le protocole le plus évolutif, particulièrement si le modèle d’HTTP demande/réponse est maintenu. SOAP est extensible, parce que les clients SOAP, les serveurs et le protocole lui-même peuvent évoluer sans rupture des applications existantes. Il est par ailleurs utile en termes de soutien intermédiaire et dans les architectures en couches. Cela signifie que le traitement des nœuds peut être réalisé avec une demande entre le client et le serveur. Ces nœuds intermédiaires traitent les parties du message spécifié par SOAP, grâce à l’utilisation des en-têtes, permettant aux clients d’identifier le nœud qui fonctionne sur telle ou telle partie du message.

Les limites de SOAP

Si les messages XML utilisés dans SOAP sont facilement lisibles par des humains, ils sont verbeux ce qui entraîne des problématiques en terme de performances :

• D’une part, le poids d’un message SOAP (codé en mode texte) est beaucoup plus important qu’un message codé en binaire, ce qui a un impact sur son temps d’acheminement.
• D’autre part, le travail de construction et de lecture du message par les applications imbriquées dans la communication est gourmand en terme de temps processeur

La première partie permettant de décrire les principes, le fonctionnement et les limites de SOAP se termine. Dans la prochaine, on analysera le modèle de traitement de SOAP, le format du message et la sécurité.

J’espère avoir répondu à vos attentes. N’hésitez pas à m’apporter votre point de vue sur cette technologie qui est en émergence.