• 20 hours
  • Hard

Free online content available in this course.

course.header.alt.is_video

course.header.alt.is_certifying

Got it!

Last updated on 12/12/19

Parlez le même langage : les formats

Log in or subscribe for free to enjoy all this course has to offer!

Les formats d’échange dans oneM2M

La standardisation des formats d’échange est nécessaire pour pouvoir effectuer des échanges de données corrects, que cela soit pour le Web ou pour l’Internet des Objets. Le HTML est bien connu sur le Web pour cela.

Prenons deux exemples pour l’Internet des Objets représentant une application :

-          AE: MON_APPLICATION

Label : premier_label; deuxieme_label

-          AE=MON_APPLICATION;

Label={premier_label, deuxieme_label}

On constate que les deux exemples donnent les mêmes informations, mais pas formatées de la même manière. Ainsi, il est difficile pour le serveur d’interpréter ces informations si elles ne sont pas normalisées.

Ce chapitre présente principalement le XML et le JSON qui sont les formats d’échange choisis par oneM2M.

Le XML : eXchange Markup Langage

Le XML, pour eXtensible Markup Language, est une représentation utilisant des balises nommées qui encapsulent des données. Ces représentations peuvent être validées par un schéma décrivant comment le XML doit être formé. Ces données peuvent être des nombres, des chaînes de caractères ou d’autres balises. Dans le cas de oneM2M, le nom des balises est standardisé et les différentes sont disponibles sur le site de oneM2M.

En-tête <?xml version="1.0" encoding="UTF-8"?>
Nœud document <m2m:ae xmlns:m2m="..."
Attribut d’un nœud rn="MY_SENSOR">
Nœud élément  <ty>2</ty>
                                 <ri>ae-CAE449907766</ri>
Nœud élément vide <lbl />
                                          </m2m:ae>
 

Tout d’abord, le XML possède un en-tête spécifiant la version utilisée ainsi que l’encodage. Ensuite, nous avons un nœud document qui précise le type de la ressource. On retrouve ensuite des sous-nœuds éléments qui sont les différents attributs. On peut avoir des nœuds vides tels que le nœud « lbl » pour lable qui signifie que la ressource n’en possède pas.

Enfin, en XML, un nœud peut avoir des attributs. Ainsi, le nœud document décrivant ici une AE possède un attribut « rn » qui représente le nom de la ressource.

Le JSON : JavaScript Object Notation

Le deuxième format est le JSON, pour JavaScript Object Notation. Cette représentation est moins verbeuse que le XML et permet de représenter de la même manière les ressources oneM2M. Une ressource est composée d’un élément principal nommé suivant la ressource, ici une ApplicationEntity. L’objet possède ensuite les attributs spécifiés de la ressource.

Utilise des accolades {
Nœud document        "m2m:ae": {
Nœud élément            "rn": "MY_SENSOR",
                                           "ty": 2,

Tableaux entre crochets  "acpi": ["/in-cse/acp-89704715"],
                                                    "rr": false
                                                     }
 

Le JSON n’utilise pas de balise, mais délimite les nœuds par des accolades. On retrouve ici l’objet principal avec un attribut qui représente le type de la ressource, comme en XML. Cet attribut a pour valeur un objet qui possède les différents attributs de la ressource. On retrouvera la représentation des tableaux en JSON, comme on peut le voir sur l’attribut acpi, pour Access Control Policy Identifiers.

La négociation de contenu

Maintenant que nous avons défini les deux types de formats que l’on peut utiliser dans les communications, il nous faut négocier avec le serveur quel format on va utiliser, et avec quel format il va nous répondre.

Cette négociation est spécifique au protocole de communication utilisé. Ainsi, nous allons prendre l’exemple du HTTP. Nous allons utiliser deux headers HTTP qui peuvent être définis lors de la création d’une requête. Le premier est le Content-Type, qui spécifie le type du contenu fourni dans la requête. Le deuxième est le header Accept. Celui-ci permet de définir quel type de format on accepte en retour de la part du serveur.

Nous allons illustrer cette négociation par un exemple. Considérons un client HTTP, sur la gauche, qui veut interagir avec un serveur oneM2M en HTTP. Le client va spécifier dans sa requête le header Content-Type, avec comme valeur application/xml pour notre cas, car il envoie le contenu sérialisé en XML. En revanche, il souhaite avoir une réponse en Json. Ainsi, il va spécifier le deuxième header qui est Accept, avec la valeur application/json. Avec ces informations, le serveur va pouvoir interpréter le contenu et ainsi traiter la requête et répondre en Json. Il spécifiera tout de même dans le header de la réponse que le contenu est en Json par le même header Content-Type, comme on peut le voir sur la figure précédente.

Example of certificate of achievement
Example of certificate of achievement