Spécifiez vos web services en pensant à l'avenir !

Je fais une parenthèse technique car j'ai lu ci-et-là des critiques concernant l'architecture SOA : l'idée n'aurait pas tenue ses promesses. Je suis de ceux qui pensent que le principe est excellent et qu'il ne s'applique pas uniquement aux applications écrites en java et aux intégrations par web services.

En revanche, il faut s'appliquer à construire des briques fonctionnelles autonomes, faciles à faire évoluer. Si l'on souhaite développer un nouveau web service, il s'agit de bien y réfléchir avant. En voici un exemple simple (et réel).

1. Le décor.

Imaginez un portail Intranet permettant d'accéder à plusieurs applications, toutes écrites sur demande pour répondre à un besoin spécifique. Imaginez ensuite un annuaire central dont le rôle est de centraliser les identifiants (login + mot de passe) et les droits d'accès de tous les utilisateurs sur toutes les applications.

Pour se connecter à chaque application, l'utilisateur doit s'identifier. Cette identification est contrôlée par l'annuaire, via un web service : il retourne une réponse positive si l'utilisateur a le droit d'utiliser l'application immédiatement ou des exceptions (codes erreurs) dans le cas contraire :

• du point de vue de l'utilisateur, si celui-ci se trompe de mot de passe, l'application affiche un message du type "vos identifiants sont incorrects, veuillez recommencer" ;
  
• si l'utilisateur n'a pas le droit d'utiliser l'application, il verra s'afficher un message du type "vous n'êtes pas autorisé à utiliser cette application" ;
  
• si le mot de passe de l'utilisateur va prochainement expirer, il verra s'afficher "veuillez modifier votre mot de passe". Ce message est complété d'un lien hypertexte vers une page intranet (url) permettant de mettre à jour le mot de passe.
  

Comment l'application connait-elle le message d'erreur à afficher ? L'url vers la page pour modifier le mot de passe ?

Comment l'administrateur peut-il modifier cela ?

2. La manière traditionnelle de coder tout cela.

Il est assez fréquent qu'un web service retourne des codes et que ces codes soient interprétés de manière libre par l'application. Dans mon exemple, des applications A et B pourraient très bien afficher des messages d'erreur différents bien qu'elles reçoivent le même code d'erreur.

La pire méthode est d'écrire ces messages et cette url directement dans le code de l'application. Dans ce cas, pour faire une modification, il faut arrêter l'application, modifier le code, tester et relancer. C'est long et il faut savoir précisément à quel endroit du code le travail doit être fait. Cette méthode est rare (sauf dans les maquettes).

La méthode traditionnelle est de placer ces messages et cette url dans un fichier texte, (appelé fichier de configuration). Lorsqu'elle en a besoin, l'application lit le fichier et récupère le bon message et la bonne url. Dans ce cas, pour modifier les messages et l'adresse, il suffit en général de modifier le fichier de configuration.

3. Exploitons plutôt le web service.

Dans mon exemple, l'accumulation de cette méthode traditionnelle fait que chaque application dispose de son propre fichier de configuration.

Si l'url permettant d'accéder à la page pour modifier son mot de passe doit être modifiée, le travail de mise à jour est donc multiplié par le nombre d'applications concernées et il ne faut pas en oublier une seule !

C'est souvent le cas lorsque l'environnement est ancien.

Evidemment, une meilleure méthode serait de faire en sorte que chaque application partage le même fichier de configuration. Ainsi il suffirait de modifier l'url à un seul endroit pour que l'information soit correctement reprise partout à la fois ! Mais là encore, ce n'est pas satisfaisant :

• il n'est pas sûr que toutes les applications, tous les logiciels de la société puissent lire le même fichier de configuration : dans ce cas, nous avons seulement réduit le nombre de fichiers ;
  
• il n'est pas sûr que l'équipe informatique en charge de l'annuaire dispose du droit de modifier les fichiers de configuration : l'information doit être distribuée aux autres équipes dans un processus de mise à jour qui peut devenir long et complexe.
  

La meilleure méthode est de faire en sorte que l'url ne soit modifiée que par l'équipe informatique en charge de l'annuaire, une seule fois. L'url ne doit donc pas être écrite dans un quelconque fichier de configuration des applications, il suffit qu'elle soit donnée directement avec les codes erreurs, via le web service.

Note : les illustrations 3D ont été réalisées avec le logiciel Bryce dont j'ai apprécié la galerie.