Présentation

L'objet du protocole CID est d'encadrer les transactions documentaires entre trois acteurs : un logiciel client à la source de la transaction ; un logiciel serveur, cible de la transaction ; un usager, à l'origine de la transaction.

Fonctionnement

Un serveur propose des processus fonctionnels. Le protocole CID permet la spécification des processus fonctionnels dédiés à des transactions documentaires dans un manifeste. Ce fichier descriptif doit être librement téléchargeable sur un serveur HTTP.

Un client est un logiciel permettant d'instancier des transactions documentaires avec un serveur. Le client doit récupérer le manifeste via une simple requête HTTP non authentifiée. Un manifeste peut décrire plusieurs transactions. En interaction ou non avec l'usager (lien numéro 3 de la figure 98), le client doit sélectionner la transaction à effectuer et exécuter les étapes qui y sont spécifiées. Ces étapes peuvent être :

  • de simples requêtes entre le client et le serveur (lien numéro 1 de la figure 98). Elles transportent alors un fichier ou des métadonnées ;

  • une interaction entre l'usager et le serveur à travers une interface web envoyée par le serveur et affichée par le client (lien numéro 2 de la figure 98).

Figure 98 : CID : un protocole entre trois acteurs

Le manifeste

Le manifeste est composé de trois parties principales : une liste de processus fonctionnels, les schémas d'authentification et les spécifications de la couche transport à utiliser.

Chaque processus est composé d'une spécification des métadonnées qu'il utilise (attendues pour l'exécution ou renvoyées en résultat d'une étape) puis de l'enchaînement des étapes attendues. Les étapes peuvent être de simples échanges de métadonnées, l'envoi de fichiers vers le serveur ou des interactions directes entre l'usager et le serveur.

La partie dédiée au transport permet de lier chacune des étapes avec des modalités de transport. CID propose exclusivement l'usage du protocole HTTP pour la couche transport. La description du transport spécifie les requêtes à utiliser (GET, PUT, POST), la façon de stocker les méta-données (en paramètre de l'URL, dans l'entête ou dans le corps de la requête), la nécessité d'inclure des propriétés de session ou encore l'usage de cookies HTTP.

1
<?xml version="1.0" encoding="UTF-8"?>
2
<cid:manifest xmlns:cid="http://www.cid-protocol.org/schema/v1/core">
3
  <cid:process>
4
    <cid:label xml:lang="en">SCORM deployment</cid:label>
5
    <cid:meta name="Content-type">
6
      <cid:value>application/xx-scorm;v1.2</cid:value>
7
      <cid:value>application/xx-scorm;v2004</cid:value>
8
    </cid:meta>
9
    <cid:upload url="http://lms.com/upload" needMetas="Content-type" required="true"/>
10
    <cid:interact url="http://lms.com/interact" required="true"/>
11
  </cid:process>
12
  <cid:authentications><cid:basicHttp/></cid:authentications>
13
  <cid:transports>
14
    <cid:webTransport needCookies="true">
15
      <cid:webInteract>
16
        <cid:request method="GET"/>
17
      </cid:webInteract>
18
      <cid:webUpload>
19
        <cid:request method="PUT" properties="queryString"/>
20
      </cid:webUpload>
21
    </cid:webTransport>
22
    </cid:transports>
23
</cid:manifest>

L'exemple précédent définit un processus de déploiement de fichiers SCORM qui se déroule en deux étapes : l'envoi du fichier (cid:upload) et une interaction entre l'usager et le serveur (cid:interact). Lors de l'envoi, le client doit spécifier le type de fichier envoyé (needMetas="Content-type"). Le serveur n'accepte que deux types de fichiers : les archives SCORM version 1.2 et version 2004 (application/xx-scorm;v1.2, application/xx-scorm;v2004). Le fichier doit être envoyé au serveur dans une requête HTTP PUT (cid:webUpload method="PUT"), la métadonnée y est stockée dans l'URL sous la forme d'une query string. Le serveur spécifie également la nécessité de support des cookies par le client afin de compléter la transaction (needCookies="true").

Pour qu'un client déploie une ressource SCORM en exploitant ce manifeste, il doit :

  1. récupérer et interpréter le manifeste par une requête HTTP GET (par exemple, vers l'URL http://www.lms.com/manifest) ;

  2. envoyer une requête HTTP PUT contenant le fichier (à l'URL http://www.lms.com/upload?Content-type=application/xx-scorm;v1.2) ;

  3. envoyer une requête HTTP GET (vers l'URL http://www.lms.com/interact) et afficher le résultat dans une frame web.

Étape Exchange

L'étape exchange spécifie un simple échange de métadonnées entre le client et le serveur. Le manifeste décrit les métadonnées attendues, l'URL à utiliser pour la requête et les métadonnées retournées. Par exemple, cette étape peut-être utilisée pour tester l'authentification et les autorisations d'un utilisateur avant l'envoi d'un fichier.

Étape Upload

L'étape upload permet de spécifier l'envoi d'un fichier par le client à destination du serveur. Ses spécifications sont du même ordre qu'une étape exchange.

Étape Interact

L'étape interact permet de spécifier une interaction directe entre le serveur et l'usager. Le serveur envoie une page web que le client doit afficher dans une frame web. L'interaction se termine par un événement Javascript personnalisé lancé au sein de la frame (cid-end-interaction). Le client peut alors récupérer des métadonnées issues de l'interaction dans le corps de l'événement puis fermer la page d'interaction. Cette étape est la principale originalité de CID. Elle permet au serveur d'ajuster la transaction en médiation directe avec l'usager sans développements ad-hoc côté client.