Overblog Suivre ce blog
Administration Créer mon blog

Articles avec #architecture logicielle tag

Architecture logicielle : Web services SOAP ou REST ?

3 Mai 2012 , Rédigé par benkirane Publié dans #Architecture logicielle

Le développement de services Web est devenu depuis quelques années un enjeu primordial pour certaines entreprises. Il permet, entre autres, de mettre à disposition à d'autres des services spécifiques à son domaine d'activité qu'ils soient gratuits ou, pour une meilleure qualité de service, payants. Les services Web offerts par google maps, par exemple, sont devenus en quelques années des standards dans le domaine de la géolocalisation. Pour leur mise en œuvre, plusieurs méthodes sont possibles: la traditionnelle basée sur SOAP et celle qui est en constante croissance, basée sur une architecture de type REST. Cet article ne se veut pas une éloge pour l'une ou l'autre des méthodes, il en résume les avantages et inconvénients. Le choix de l'utilisation de l'une ou l'autre doit bien être l'aboutissement d'une étude des besoins de chaque entreprise en fonction de son contexte propre.

SOAP

Au départ, les architectes d'entreprise ont privilégié les services Web de type SOAP. Les principaux avantages de ce protocole étant:
  • l'indépendance vis à vis du langage de programmation,
  • l'indépendance vis à vis de la plateforme où ils sont déployés,
  • son extensibilité,
  • l'utilisation du standard XML pour l'échange des messages,
  • le contenu des messages échangés qui incluent le format d'échange cela permet d'avoir un contrat personnalisé entre le fournisseur et le consommateur du service,
  • l'utilisation du protocole HTTP pour le transport qui permet de s'affranchir des problématique de firewalls: en réalité SOAP est indépendant de la couche de transport puisqu'il l'a redéfini (entête, format d'échange, type des données échangées, ...). Cependant, HTTP est le protocole de transport le plus largement utilisé par SOAP.

Ces avantages devaient permettre une interopérabilité entre des applications hétérogènes développées en Java, .NET ou PHP. Cependant, les architectes ont été confrontés à des problèmes parmi eux:

  •  SOAP étant extensible, plusieurs standards sont apparus, regroupés sous la forme WS-* :

    WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, etc. Leur nombre croissant a abouti à l'augmentation de la complexité perçue de SOAP. De plus, des différences d'implémentations ont aboutis à des problèmes d’interopérabilité entre applications hétérogènes. 
  • pour que les applications puissent interagir entre elles, la description des Web services en WSDL et la définition d'un dictionnaire de données sont nécessaires dans l'entreprise. Cependant, dès qu'une erreur de conception de ce dictionnaire apparaît, l'implémentation des services Web devient problématique et couteuse. Ajoutée à cela, le coût de mise en œuvre des fichiers de description des services Web (le WSDL) et des fichiers de données (XSD). En résumé, le coût de mise en œuvre est souvent très élevé.
  • La conception des services Web en elle-même. Si un service est mal conçu, et cela peut arriver très vite, le nombre de données qu'il renvoie peut-être très important. Ajoutée à cela, la verbosité de SOAP, très rapidement, des problèmes de performance sont rencontrés qui induisent souvent à une remise en cause de la conception elle-même des services.

Le coût et la complexité d'implémentation générés par les inconvénients de SOAP ont remis en cause, complètement, les avantages de son utilisation. Les réseaux sociaux, dans un premier temps, avec leur volume de données échangées puis les autres entreprises, ensuite, se sont positionnées sur un autre moyen de mettre en œuvre des services Web moins couteux, plus simple à implémenter et surtout plus efficace. Cette méthode qui n'est pas nouvelle puisqu'elle est basée sur les fondamentaux du protocole HTTP est l'architecture REST (cf. mon billet précédent sur ce thème).

REST

Les architectures de type REST deviennent, de plus en plus, des standards dans les entreprises aujourd'hui. La plupart des consultants en informatique de gestion vous le diront. Cependant, au delà de l'effet de mode, la mise en œuvre de services Web basée sur cette architecture a de quoi séduire. Les principales motivations pour le choix de cette architecture sont:

  • l'indépendance vis à vis du langage de programmation,
  • l'indépendance vis à vis de la plateforme sur laquelle ils sont déployés,
  • la plus grande simplicité d'implémentation car la couche transport n'a pas besoin d'être redéfinie et il n'est plus nécessaire de créer un dictionnaire de données comme on le fait avec SOAP.
  • la non intégration du format d'échange au sein des messages. Cela induit une verbosité beaucoup plus faible et donc une performance accrue et une plus grande souplesse dans l'implémentation,
  • l'utilisation de multiples formats pour l'échange de données (XML, JSON, HTML),
  • qu'elle est plus proche de la conception et de la philosophie initiale du Web (URI, GET, POST, PUT et DELETE),
  • pas de gestion d'états du client sur le serveur.

Comme les services Web de type SOAP, ceux basés sur l'architecture REST ont le gros avantage d'être interopérables et indépendants de leur environnement de déploiement avec, en bonus, de meilleures performances. Cependant, ils ont des défauts conséquents à leur adhésion au protocole de transport HTTP:

  • une limitation en matière de sécurité,
  • il n'est pas fiable et ne garantit pas la bonne transmission des messages,
  • la limitation en terme d'actions possibles (CRUD uniquement),
  • les navigateurs actuels implémentent mal les opérations PUT et DELETE.
Dans la réalité, ces limitations ne sont pas vraiment un frein. La sécurité peut-être introduite de plusieurs façons différentes (tokens d'authentification, HTTPS, des outils comme Spring security en java). Les problèmes de standardisation des navigateurs sont détournés par surcharge de la méthode POST. Le vrai frein au choix de REST pour la mise en oeuvre de Web Services est le besoin propre à chaque application.

Conclusion

Internet existe depuis plusieurs décennies maintenant et, avec le retour des architectures REST, on peut se rendre compte que pendant ces années, beaucoup ont perdu les fondamentaux même du protocole HTTP. Les navigateurs, eux-mêmes, ne l'implémentent pas convenablement, ce qui est un comble. De mon point de vue, en tant que professionnel du Web, le plus grand avantage de REST est de revenir aux sources de la toile comme l'ont pensé ses créateurs. Le Web n'est pas un ensemble de pages HTML mais un ensemble de ressources dont l'une des représentations est le HTML. D'autres sont possibles comme JSON, XML, PDF, etc... Sur ces ressources, il est possible d'effectuer 4 opérations principales qui sont GET, POST, PUT et DELETE, du CRUD en résumé.

Ceci est important, lorsqu'on réfléchit au choix d’architecture logicielle. Si vos services Web sont orientés action (plus complexes que les opérations simples du CRUD) et qu'ils nécessitent une sécurité élevée ou un contrat rigide d'échange, SOAP sera, souvent, le protocole le plus adapté.

Si vos services Web sont orientés ressources avec des opérations simples sur celles-ci, REST sera le choix le plus judicieux. Le développement de ces services se focalisent plus sur l'identification des ressources. REST impose le reste de la conception par la possibilité d’implémenter les 4 actions ou verbes (HTTP) du CRUD.

 

Lire la suite

REST (Representational State Transfer): l'architecture logicielle basée sur les fondamentaux d'internet

22 Juin 2011 , Rédigé par benkirane Publié dans #Architecture logicielle

L'architecture logicielle la plus utilisée aujourd'hui dans le développement d'applications Web est, sans aucun doute, l'architecture MVC 2 (Model View Controller). On entend donc, un peu moins, parler de l'architecture REST. Le terme a, pourtant, été créé par Roy Fielding en 2000.

Roy Fielding étant l'un des principaux acteurs de la spécification HTTP, l'architecture qu'il propose est, logiquement, basée sur les concepts fondamentaux du W3C:

  • - l'URI: elle permet de nommer et identifier une ressource
  • - le protocole HTTP fournies toutes les méthodes (GET, POST, PUT et DELETE) nécessaires à l'interaction avec cette URI
  • - chaque opération est auto-suffisante, il n'y a donc pas de conservation d'état
  • - les standards XML et HTML sont utilisés pour faire les liens entre les différentes URI et, ainsi, naviguer dans une application REST.

Cette architecture, très évolutive, tends à concurrencer les architectures orientées services de type SOA. Elle se pose en alternative des protocoles RPC et SOAP et est sensée être plus simple à mettre en œuvre. Comme j'ai découvert cette architecture il y a peu et que je ne l'ai jamais encore mise en œuvre, je confirmerais ou infirmerais cette simplicité lorsque je l'aurais réellement mise en œuvre. Ceci sera le sujet d'un futur billet, j'espère dans quelques mois :))).

Pour plus de détails sur les avantages et inconvénients de cette architecture cités par Roy Fielding lui-même, vous pouvez consulter wikipédia à l'adresse suivante: http://fr.wikipedia.org/wiki/Representational_State_Transfer.

Même si cette architecture repose sur des standards du Web, il faut bien noter que REST n'est pas en soi un standard. Il n'existe pas de spécification du W3C pour la décrire.

Lire la suite