lundi 16 avril 2012

Du style pour vos services web : la théorie


De nos jours, les piles logicielles pour implémenter des services webs sont légions.
De plus, la plupart de ces piles proposent des approches de développement très productives : JAX-WS et JAX-RS par exemple.
Mais ces piles abordent les aspects techniques des services webs : sérialisation XML, espace de nommage, génération de client, ...
Elles ne sont que de peu d'utilité pour adresser des questions parfois complexes:
  • comment gérer les changements ?
  • quelle est le mode d'invocation qui apporte la plus grande scalabilité ?
  • comment obtenir une API de service web cohérente avec le métier du SI ?
  • quel style pour quel client ?


   Cet article se propose de répondre à quelques questions par l'entremise du style.


Le style RPC


Le style RPC (Remote Procedure Call) consiste à exposer une procédure distante plus ou moins telle que l'originale, c'est à dire avec la même signature que la procédure invoquée sur le système d'information distant.
Ce style a permet de coller au plus près de la couche métier du SI cible.
Cependant, il comporte des inconvénients :
  • les clients du service web peuvent être cassés si la signature de la procédure change.
  • la logique métier du SI distant est exposée directement ce qui peut poser des problèmes au client : granularité des objets métiers, complexité, performance

Très souvent, un service RPC sera appelé en mode synchrone :

Enfin, un service web de style RPC peut être invoqué de manière asynchrone.

Cela se passe en deux temps, d'abord le client invoque le service web et reçoit un accusé de réception. Enfin, le service web rappelle le client (callbak) lorsque le résultat est prêt. La pile JAX-WS supporte ce mode asynchrone.
Une autre manière d'implémenter un service asynchrone consiste non pas à reposer sur un composant technique mais à prévoir ce mode dès les spécifications fonctionnelles du service.
Le service web concerné renvoie un accusé de réception qui contient un code retour et un identifiant d'appel. Un deuxième service est proposé pour récupérer le résultat de l'appel : le client doit alors implémenter une logique de polling pour obtenir le résultat.


Le style Message


Le style Message consiste à échanger des messages dont le contenu sera analysé par le système d'information distant pour sélectionner la procédure à invoquer.
Généralement, l'API du service web propose un type de message pour l'invocation du service et un autre type pour la réponse.
La forme réelle de la procédure métier du SI est complètement cachée, il s'agit d'une reformulation complète via le concept de messagerie. L'API du service web est taillée sur mesure pour les besoins du client. Les procédures métiers du SI distant ont dans ce cas un rapport très lointain avec l'API du service web.
Ce style convient quand :
  • un grand nombre de procédure sont disponibles avec une sémantique proche : l'encapsulation des informations d'invocation et de réponse suivant le pattern Message permet de limiter le foisonnement de l'API du service web.
  • les informations nécessaires à l'invocation sont complexes et variées : lorsque de nombreux arguments sont nécessaires comme des informations métiers (heure de départ, nombre de passager, ...) et techniques (version de la procédure, format de retour, compression, ...)
  • le SI distant change fréquemment
Ce style est plus volontiers mis en oeuvre sur un mode asynchrone : le client n'est dans ce cas pas bloqué par l'invocation du service web.
Il reçoit dans un premier temps un accusé de réception qui lui indique simplement si le message a été correctement reçu.
Ensuite le service web traite la demande éventuellement en s'appuyant sur un dispositif asynchrone de type messagerie (JMS) ou évènementielle (SEDA) .
Lorsque la demande est traitée alors le client est informé du résultat de cette demande via un message de réponse.
Si le client tolère le mode asynchrone alors il est possible d'atteindre un haut niveau de scalabilité.
Il peut être pertinent d'utiliser le pattern Builder pour aider le client à construire des messages pour l'invocation du service ou à lire les messages de réponse.






Le style Resource



Le style Resource s'appuie sur les préceptes définis par l'architecture REST.

Le protocole HTTP est utilisé comme cadre conceptuel et technique pour définir et implémenter les services.

Tout est ici "ressource" que le client peut toucher via une URI associée à une seule et même ressource.
Une ressource peut par contre être touchée via plusieurs URIs.

Le protocole HTTP définit des verbes qui ont une sémantique précise :

- GET pour obtenir la représentation d'une ressource
- PUT pour créer ou mettre à jour une ressource
- DELETE pour supprimer une ressource
- POST peut être utilisé comme PUT ou DELETE (environnement ou ces verbes sont interdits) ou pour des comportements qui ne rentrent pas dans les cases PUT ou DELETE.
- ...

HTTP propose aussi :
- des codes de retour : 200, 404, 500, ... qui seront eux aussi utilisé par vos services REST pour communiquer le résultat des opérations.
- une gestion des représentations via les types MIME

Enfin, HTTP définit certains verbes comme idempotents : GET, HEAD, OPTIONS ne doivent pas provoquer de changement d'états quelque soit le nombre d'invocations.

Quant à POST, DELETE, PUT, ils ne sont pas idempotents.


Les opérations que vous proposerez à vos clients devront rentrer dans les cases conceptuelles définies par REST et HTTP. Par exemple, une requête HTTP est structurée d'une certaine manière (paramètres encodés) et contient uniquement des données au format texte.

Si cela vous convient alors ce style peut vous apporter beaucoup :

- un cadre conceptuel, technique robuste et bien connu
- des possibilités d'optimisation via des mécanismes de cache
- des facilités de support de clients variés
- toléré par les mécanismes de sécurité tel que les parefeux
- particulièrement adapté et performant dans le contexte d'applications RIA (ajax)




Nous avons vu trois styles de conception pour vos services webs : indépendamment de toute pile technique, il est important de bien connaître ces styles et leurs applications.


Nous verrons dans d'autres articles des implémentations concrètes de ces styles.




Contrat Creative Commons
the jee architect cookbook by Olivier SCHMITT est mis à disposition selon les termes de la licence Creative Commons Paternité - Pas d'Utilisation Commerciale - Pas de Modification 3.0 Unported.

Aucun commentaire:

Enregistrer un commentaire