La question ne se pose pas sous l'angle de "sérieux" ou pas. Celle-ci doit plutôt être évaluée sur le plan de la composition de services Web et de l'orchestration de ceux-ci dans un processus (ou service Web) de granularité plus importante.
Tant que le service Web est simple, ou contrôlé de bout en bout par le même éditeur, l'utilisation de SOAP n'est pas nécessaire. Comme le signale Alexander, la description WSDL du service Web en question peut uniquement spécifier une liaison (binding) vers le protocole HTTP pour accéder au service et ne pas imposer une liaison vers le protocole SOAP.
En revanche, dès que le service Web est plus complexe, ou bien est construit par composition de plusieurs services Web de granularité plus fine, la question doit être posée et l'usage de SOAP peut s'avérer obligatoire dans la grande majorité des cas.
A partir du moment ou l'interaction entre le client et le serveur est asynchrone (ce point peut être contourné par la mise en oeuvre du pattern Ajax en liaison HTTP), que les traitements du processus doivent être entièrement ou partiellement transactionnés, que la sécurité doit être assurée de bout en bout (y compris en relation avec des prestataires de services Web en extranet ou internet), l'usage du protocole SOAP devient incontournable car ces concepts n'existent pas dans le style architectural orienté-ressources du Web.
La mise en oeuvre de ces fonctionnalités d'infrastructure passe par l'utilisation d'en-têtes SOAP particuliers spécifiques à chacune des problématiques d'infrastructure à prendre en compte.
Le schéma ci-dessous, extrait du document "Secure, Reliable, Transacted Web Services: Architecture and Composition" publié conjointement par IBM et Microsoft en septembre 2003, illustre parfaitement cette question.
Dans ce contexte de gestion d'infrastructure, il devient nécessaire de prendre en charge l'une ou l'autre (ou l'intégralité) des problématiques suivantes :
- le routage et l'adressage des messages (spécification WS-Addressing du W3C) ;
- l'échange fiable des messages entre services Web (spécification WS-ReliableMessaging) ;
- la coordination entre services Web (spécification WS-Coordination) ;
- la gestion des transactions courtes (WS-AtomicTransaction) ou longues (WS-BusinessActivity) ;
- la gestion de la sécurité (framework WS-Security).
Qu'en conclure ? En pratique, les deux styles d'architecture (orientée-ressources et orientée-services) ne s'opposent pas, mais sont complémentaires. Les caractéristiques des services Web considérés doivent piloter le choix. Un service Web tel que Google Maps est simple (fonctionnement en consultation uniquement, contrôle total par l'éditeur, pas de composition de services Web, ...) : dans ce cadre, l'usage de SOAP n'apporte rien. En revanche, un service Web de réservation en ligne, utilisant les services de centrales de réservation prestataires de services (réservations aériennes, hôtelières, automobiles, ...), aura besoin de s'appuyer sur des services d'infrastructure et devra nécessairement mettre en oeuvre le protocole SOAP avec ses partenaires. Cependant, l'interaction entre l'utilisateur et le service Web de réservation en ligne pourra éventuellement être réalisée via une liaison HTTP sans utilisation de SOAP.
De mon point de vue, dans le cadre de services qui mettent en oeuvre une interaction homme-machine (type Web 2.0) ou machine-machine simple, le choix du protocole doit être laissé aux utilisateurs, comme le font certains nouveaux services tels que Flikr (REST, SOAP ou XML-RPC) par exemple. Dans le cadre d'interactions homme-machine ou machine-machine plus complexes, la question ne se pose plus et l'utilisation de moteurs SOAP devient impérative.
Technorati tags : soap rest wsdl infrastructure composite applications
Del.icio.us tags : soap rest wsdl infrastructure composite applications
Aucun commentaire:
Enregistrer un commentaire