Introduction aux services web

La communication de machine à machine

Faire communiquer deux machines entre elles a toujours été le souci des ingénieurs. Une machine échange des informations avec une autre machine, soit dans un seul sens, soit dans les deux sens.

Par exemple, un lecteur de carte est une machine. elle va analyser le contenu d'une carte, puis transmettre son résultat à une autre machine pour générer une action.

Les premiers protocoles en binaire

Il y a communication de machine à machine, que nous abrégerons par M2M, dans laquelle les signaux échangés ne sont plus des commutations électriques, mais des codes dans un format donné:

• un relais qui active ou désactive un circuit d'alimentation électrique n'est pas une communication M2M;
• un signal binaire codé, par exemple "CR" peut être assimilé à une communication M2M.

Dès les débuts de l'informatique, avant qu'il n'y ait des écrans, l'affichage était réalisé par des terminaux télétypes. Le retour à la ligne du chariot d'écriture était commandé par l'instruction "CR". Il était alors fréquent de voir des terminaux télétypes parfois très éloignés de l'unité centrale, reliés par des transmissions synchrones ou asynchrones sur support téléphonique ou autres. La capacité à agir physiquement sur le terminal télétype peut s'assimiler à une communication M2M.

Les protocoles les plus simples, dans les débuts de l'informatique se résumaient à des codes bien spécifiques qu'on retrouve encore dans le code ASCII:

• CR pour provoquer un retour en début de ligne (Carriage return)
• LF pour provoquer un saut de ligne (Line Feed)
• FF pour provoquer un saut de page (Form Feed)
• BEL pour faire sonner le terminal (bip ou sonnette)

Les échanges de textes plats

Les commandes Hayes (ou commandes AT) sont utilisées par les modems téléphoniques analogiques pour les commander. Exemple, pour numéroter:

  ATDT0123456789

appelle le numéro de téléphone 0123456789

De même, le modem peut être mis en attente d'une transmission entrante. Dès la réception d'une sonnerie téléphonique, le modem transmet le texte "RING" vers l'ordinateur.

Nous retrouvons là un mode de communication M2M avec des commandes sous forme de texte.

Dès que les machines se sont multipliées et corrélativement des réseaux, il apparut rapidement une demande en matière de transfert de données. Beaucoup de systèmes échangent encore des données au format texte plat. L'exemple le plus courant est l'extraction de données au format CSV. Ce format CSV est une première ébauche de structuration des informations dans la communication M2M. Exemple de données CSV:

code_postal;commune
11250;SAINT HILAIRE
77240;CHAMPS SUR MARNE
90000;BELFORT

Inconvénient des fichiers textes plats

Le principal inconvénient dans la transmission des données sous forme de fichiers de texte plat est qu'il est très difficile d'avoir des données homogènes:

• différences dans les codages de caractères, en particuliers les caractères accentués
• différences dans les éléments de séparation des lignes: CR, CR+LF, LF, etc...
• différences dans les séparateurs de champs: ";", ",", tabulation, etc...
• impossibilité d'utiliser un séparateur de champ dans le contenu d'une information
• les données sont non-typés

Le plus gros inconvénient est que la structure même des données, une fois fixée ne peut guère évoluer, sauf à contraindre tous les systèmes consommateurs à faire évoluer les programmes. Par exemple, si on fait évoluer notre exemple qui diffuse les codes postaux et communes en rajoutant d'autres colonnes, on risque de perturber les systèmes qui ne prennent en compte strictement que deux colonnes.

Les flux de données structurés

Parmi les type de données échangés dans les relations M2M, les données au format XML ont rapidement rencontré un vrai succès. Voici un exemple de fichier XML qui remplace parfaitement les données au format CSV:

<communes>
    <item>
        <code_postal>11250</code_postal>
        <commune>SAINT HILAIRE</commune>
    </item>
    <item>
        <code_postal>77240</code_postal>
        <commune>CHAMPS SUR MARNE</commune>
    </item>
    <item>
        <code_postal>90000</code_postal>
        <commune>BELFORT</commune>
    </item>
</communes>

Si on rajoute de l'information, on ne perturbera plus une machine consommatrice, exemple:

<communes>
    <item>
        <code_postal>11250</code_postal>
        <commune>SAINT HILAIRE</commune>
        <longitude>2.310505</longitude>
        <latitude>43.093713</latitude>
    </item>
...etc...
</communes>

Ici, pour chaque commune on rajoute les géo-coordonnées de la commune. Ainsi, le système qui n'exploite pas ces nouvelles données pourra les omettre au traitement.

C'est ce format XML que nous allons privilégier, le seul d'ailleurs disponible pour les serveurs REST et SOAP disponibles avec Zend Framework.

Nous allons maintenant voir les notions de serveur et de consommateur de services web: les fournisseurs et consommateurs M2M