[Web Service][SOAP] Deux types d'accès

Bonjour,

Après avoir fait notre webservice (rpc/encoded) pour notre utilisation en interne, tout en php avec un frontend qui vient l'interroger tout semble fonctionner correctement (dans les 40 fonctions qui retourne des données).

Maintenant est venu l'heure de l'intégration de notre webservice par nos client.

Certain de nos gros client, nous demande maintenant un webservice.
Les langages qui vont interroger notre webservice pourront être principalement perl, java, php, .net

Certains nous demandent donc soit du rpc/encoded (qui est de toute façon à garder pour la compatibilité avec l'existant) ou du document/literal.

J'ai donc compris que les méthodes ne peuvent pas être appelés de la même façon quand on est en rpc/encoded ou en document/literal

RPC/ENCODED
function add(valeur1, valeur2)

DOCUMENT/LITERAL
function add($params)

avec $params = un objet contenant $params->valeur1 et $params->valeur2


Ma question est donc, est ce qu'il faut réaliser deux points d'accès pour chaque type de style ?

N'existe pas une façon de détecter le style lors de chaque requête afin d'utiliser les bonnes déclaration pour le serveur soap.
En épluchant par exemple les WSDLs d'OVH (pour ne pas les citer), j'ai vu qu'ils proposent les deux WSDLs qui pointent vers le même point d'accès.

Il est très difficile de trouver de l'information sur la mise en œuvre de webservice.

Bonjour.

Il y a pas mal de choses erronées dans ce tu exposes.

Premièrement, les "couples" rpc/encoded et document/literal n'ont rien de systématique.

Pour ma part je travaille actuellement en rpc/literal pour des raisons que je ne détaille pas car c'est sans interêt pour ta question.

Deuxièment, "rpc" (remote procedure call) correspond à des messages soap nommant une procédure à éxecuter accompagnées de ses paramètres, tandis que "document" correspond à des requêtes soap "libres" dans leur format, que le serveur se doit de savoir interpréter selon des spécifications préétablies (bref, un document:)). Ce qui n'exclut pas que le document contienne de quoi identifier une opération/procédure à réaliser accompagné d'éventuels paramètres.

Les différentes façons de passer les paramètres que tu évoques dans ton post sont donc également indépendantes du fait qu'on soit en rpc ou en document.

Proposer 2 wsdl parait une bonne piste, la clé est de soigneusement et astucieusement définir les messages dans chacun des wsdl pour qu'ils puissent être pris en charge par le même code côté serveur moyennant un minimum d'ajustements (par exemple développer une fonction/méthode capable de reconnaître la version 'document' des requêtes et de les transformer en leur équivalent 'rpc', pour unifier le code en aval, etc...)

Merci pour ta réponse,

Citation:

---

Envoyé par pandrogynik

Les différentes façons de passer les paramètres que tu évoques dans ton post sont donc également indépendantes du fait qu'on soit en rpc ou en document.

---

Il faut savoir qu'aujourd'hui je n'ai pas trouvé comment gérer de la même façon un appel en RPC/ENCODED qu'un appel en DOCUMENT/LITERAL wrapped (que j'ai mal précisé au départ) au niveau du code.
Après plusieurs tests, j'en est déduit que l'appel à une méthode en Document/literal, je doit forcément avoir un seul paramètre (objet) sinon cela
ne fonctionne pas.

Si tu as des pistes je suis preneur.

Citation:

---

Envoyé par pandrogynik

Proposer 2 wsdl parait une bonne piste, la clé est de soigneusement et astucieusement définir les messages dans chacun des wsdl pour qu'ils puissent être pris en charge par le même code côté serveur moyennant un minimum d'ajustements (par exemple développer une fonction/méthode capable de reconnaître la version 'document' des requêtes et de les transformer en leur équivalent 'rpc', pour unifier le code en aval, etc...)

---

Sinon le dernier point que tu aborde est ce que je souhaite obtenir.

Sachant qu'en fait il a donc été choisi de faire du
- RPC/Encoded => pour la compatibilité avec l'existant.
- Document/literal wrapped => Pour la comptabilté avec les grands entreprises qui veulent utiliser ce "standard" et je pense surtout être comptabile avec les produits Microsoft.

Mais comment à partir du serveur de service pourrait-on détecter en PHP que le client fait une requête de tel ou tel sorte, de manière simple ?

Difficile de rentrer rapidement dans le détail sur ce point...

Dans le contexte d'un "paire de WSDL" donnée, les versions doc ou rpc des requêtes entrantes auront chacune une forme caractéristique reconnaissable moyennant un peu de parsing XML.
Donc avant de lancer le traitement des requêtes par un SoapServer::handle ou autre, il faudra récupérer les POST DATA via le php://input et parser la requête jusqu'à obtenir l'information discriminante, et agir en conséquence.

Si le document/literal est proposé comme standard, il vaut mieux faire l'inverse que ce que je proposais précédemment bien sur, c.a.d repérer les requêtes RPC pour les transformer en leur pendant doc/literal.


Pour le document/literal, il ne s'agit pas "d'un seul paramètre objet" mais d'un document répondant à un schéma. Ca ressemble à "un seul paramètre objet dans le contexte RPC", parce que comme tout document XML, il y a un élement racine unique. Mais le RPC et le document ne sont théoriquement pas comparables.

Pour exprimer plus généralement mon avis (même si ça ne changera rien à ta situation) sur la tendance du document/literal comme standard, je ne suis pas d'accord avec le fond même de la question.

Quand on veux s'échanger des documents, et bien on le fait, avec du "document" (exemple, on envoie une liste de catégories de produits, et on reçoit le catalogue des produits disponibles dans ces catégories chez un fournisseur).

Quand on veux éxecuter une procédure distante, passer des paramètres pour obtenir un résultat post-traitement, et bien on fait du RPC.

Il n'y a pas lieu pour moi de choisir un standard entre les deux cas, ce sont 2 solutions correspondant à 2 problématiques, et les inconvénients liés à l'un et à l'autre (facilités ou difficultés de maintenance, d'évolution etc...) sont liés à la problématique d'origine, en amont du choix d'exposer les fonctionnalités concernées par le biais d'un service web ou d'autre chose.