Et tu n'as toujours pas répondu : mal gaulé ça n'avance pas à grand chose comme argument.
C'était pourtant le but du paragraphe qui suivait:
SOAP n'a pas été correctement pensé. Au tout début, il a réglé des problèmes simples (comme pouvait le faire XML-RPC) et à proposer ensuite un maquis d'extensions pour boucher les trous. Tout cela a été péniblement intégré dans la pile WS-I. Côté serveur: seul Java me semble aujourd'hui capable de traiter du SOAP correctement (j'imagine que .NET aussi après tout). De plus le support client SOAP est loin d'être complet dans la plupart des langages de programmation ce qui pose quand même un problème sur sa pérennité et son idéal agnostique.
Pour être plus précis, SOAP est vendu comme solution de SOA mais très souvent tu n'as même pas de WSDL qui va bien ou un registre UDDI correct. On te vend une complexité superflue là où du XML-RPC ou du REST peuvent très souvent faire l'affaire.
SOAP est trop souvent utilisé comme un bus logiciel alors que c'est exactement là où il est le plus inefficace (en terme de charge réseau ou de puissance de calcul nécessaire pour le parsing).
Les normes des extensions sont exclusivement poussées par les grands éditeurs qui font en sorte de protéger leurs logiciels maisons. Au final, très peu de compatibilité et de coopération possible.
Pour les alternatives, j'en donne quelques-unes plus bas dans le fil.
[^] # Re: Sans être fan du tout
Posté par Vroum . En réponse au journal XML c'est de la daube!!!. Évalué à 1.
C'était pourtant le but du paragraphe qui suivait:
Pour être plus précis, SOAP est vendu comme solution de SOA mais très souvent tu n'as même pas de WSDL qui va bien ou un registre UDDI correct. On te vend une complexité superflue là où du XML-RPC ou du REST peuvent très souvent faire l'affaire.
SOAP est trop souvent utilisé comme un bus logiciel alors que c'est exactement là où il est le plus inefficace (en terme de charge réseau ou de puissance de calcul nécessaire pour le parsing).
Les normes des extensions sont exclusivement poussées par les grands éditeurs qui font en sorte de protéger leurs logiciels maisons. Au final, très peu de compatibilité et de coopération possible.
Pour les alternatives, j'en donne quelques-unes plus bas dans le fil.