Clever Age a publié dans sa newsletter une excellente et didactique synthèse sur l’interopérabilité J2EE, .NET et PHP. J’en retiens les leçons suivantes :
- Pour l’intéropérabilité, le couplage lâche c’est LE principe qu’il faut adopter
- Les services web basés sur la pile de technologies liées à SOAP, c’est pas mal pour faire du couplage lâche
- Mais les services web basés sur la technologie XML-RPC ou les services Web de style REST (quelle que soit la techno utilisée), c’est encore mieux car
- plus simple
- une pratique plus répandue
- ça apporte moins de contraintes techniques inutiles (infrastructure, compétences, …)
J’ajouterais que les services Web de style REST offrent un couplage non seulement encore plus lâche (modularité du S.I.) mais également encore plus tardif : inutile, au moment de la conception de vos services Web, de faire des hypothèses sur l’usage qui en sera fait dans le futur, le style REST vous garantit leur intégrabilité future.
La différence essentielle entre le style REST et le style RPC (XML-RPC ou pile SOAP), c’est que le style REST permet l’intégration spontanée (non planifiée centralement) de services alors que la pile SOAP suppose une planification plus centralisée des projets d’intégrations de services à travers la négociation et la spécification de contrats entre fournisseurs et consommateurs de services (et qui dit contrat dit « une certe forme de codification » et donc une certaine perte de flexibilité pour le futur).
Ma conclusion : l’approche REST est plus adaptée aux organisations qui sont elles-mêmes faiblement couplées. Autrement dit : pour faire du SOA sur SOAP, il faut réunir toutes les parties prenantes et établir des contrats de services spécifiques et peu évolutifs ; conséquence : faites du SOAP dans une organisation non centralisée et vous vous retrouverez dans une situation similaire à celle dont se lamentait Reinout Van Rees, une situation qui conduit à l’échec ou au moins au gaspillage d’efforts. Posez-vous plutôt la question :
- Vous vivez dans une cathédrale ? Alors vous pouvez vous contenter du couplage relativement faible offert par SOAP mais vous vous encombrez toute de même de contraintes inutiles
- Vous vivez dans un bazar (« bordel organisé » disait Fred ?) ? Alors il vous faut du couplage extrêmement lâche et tardif. Et l’interopérabilité des composants du bazar passe alors par la simplicité et le caractère « future-proof » de REST.
Au bout d’un moment, j’ai l’impression de me répéter à force de ressasser les mêmes choses sur REST. Mais j’espère que d’un billet à l’autre, mes idées sur le sujet gagnent en clarté (au moins dans ma tête). Et les vôtres ?
A noter : cet article de Clever Age a également été publié chez ZDNet, ce qui est une bonne chose pour donner un éclairage médiatique aux approches pragmatiques pour l’intégration.
« Vous vivez dans un bazar ? Alors il vous faut du couplage extrêmement lâche et tardif. » Voir qui n’arrive jamais… Car je rappelle quand même que le contenu d’un message (qu’il soit en REST ou en XML Protocol aka SOAP) fait forcément l’objet d’une spécification. Que vous fassiez intervenir vos partenaires dans l’élaboration de son contenu n’a absolument rien à voir avec le choix de la technologie. Donc hors sujet!
Quand à la technologie, en elle même, prenez REST et vous devrez vous en contenter. Prennez XML Protocol et vous avez la guarantie (pérénité) d’avoir une NORME amenée à prendre en compte vos futurs besoins tel la sécurité, la fiabilité, l’adressage (bref tous le reste :)) grâce à son EXTENSIBILITE.
Soit dit en passant la chronique CleverAge est en effet plutôt bien… mais alors Foward Motion ou Stop Energy ???
> Car je rappelle quand même que le contenu d’un message (qu’il soit en REST ou
> en XML Protocol aka SOAP) fait forcément l’objet d’une spécification. Que vous
> fassiez intervenir vos partenaires dans l’élaboration de son contenu
> n’a absolument rien à voir avec le choix de la technologie. Donc hors sujet!
Mmm… Je pense que nous ne sommes pas d’accord. En effet, de mon point de vue, la « manière » (c’est plus une manière de faire qu’une technologie) REST de faire des services web me semble faciliter l’intégration des-dits services par des partenaires n’ayant pas participé à leur spécification, i.e. par des « retardataires ». Autrement dit : avec les services de type RPC, on expose une interface de programmation auquel le partenaire devra apprendre à « se brancher » si il n’a pas influencé la conception de cette interface de manière à se qu’elle se branche facilement sur ses propres systèmes. A contrario, dans le style REST, l’idée est d’exposer une interface de style « documentaire », autrement dit d’exposer des ressources qui se présentent comme si elles étaient passives. Le partenaire qui n’a pas participé à la conception n’a plus alors qu’à « ramasser » les ressources en question. Et si celles-ci ont effectivement été mises en place selon les règles de l’art REST, elles contiennent leur propre mode d’emploi : leur sémantique est explicite ! Inutile alors de recourir à des NORMES supplémentaires telles que WSDL pour le mode d’emploi du service ou à UDDI pour l’inscription dans un annuaire de service.
> Quand à la technologie, en elle même, prenez REST et vous devrez vous en
> contenter. Prennez XML Protocol et vous avez la guarantie (pérénité) d’avoir une
> NORME amenée à prendre en compte vos futurs besoins tel la sécurité, la
> fiabilité, l’adressage (bref tous le reste :)) grâce à son EXTENSIBILITE.
Mon point de vue est que les normes de la famille SOAP ne sont pas forcément utiles dans la mesure où les normes existantes (HTTP, XML, RDF, …) sont plus stables, plus pérennes, et couvrent aussi bien tous les besoins futurs de sécurité, de fiabilité, d’adressage et fournissent déjà toute l’extensibilité requise.
La seule véritable nouveauté apportée par la famille SOAP est l’indépendance du transport sous-jacent (HTTP, SMTP, …) ce qui permettrait de faire des services web aussi bien accessibles via SMTP que via HTTP. Mais je ne crois pas que les cas d’utilisations correspondants soient suffisament courant pour justifier de l’intérêt de ces normes.
> Soit dit en passant la chronique CleverAge est en effet plutôt bien… mais alors
> Foward Motion ou Stop Energy ???
Euh… C’est-à-dire ? Que faire ? Eh bien, pour ma part, je mise sur les services web. Je choisis simplement de continuer une architecture qui a fait ses preuves : celle du WWW (aka REST) et j’évite tant que je peux m’en passer les complications à la mode (SOAP, …) ; au contraire, je mise pour aller plus loin sur RDF, OWL et Cie.
Attention, la chronique est maintenant là, une erreur lors de notre changement de site : http://www.clever-age.com/article.php3?id_article=273
Le principal avantage de REST face à SOAP, a mon sens, c’est qu’il suffit d’avoir une plateforme existante sachant traiter du XML et exploiter HTTP, et c’est souvent le cas.
Avec SOAP, il est nécessaire de faire évoluer la plateforme pour ne pas avoir à tout faire soi-même, que ce soit en changeant de version ou en ajoutant un framework complémentaire. En environnement professionnel, cela peut être difficile voir impossible.
Le problème de REST par contre, c’est qu’il faut beaucoup plus être verbeux dans la documentation des services offerts, puisqu’il n’y a pas de formalisme standard de description équivalent à WSDL.