Quelqu'un peut-il m'expliquer les différences entre un style Document et un style RPC pour les services Web?
Il existe deux modèles de style de communication qui sont utilisés pour traduire un binding WSDL en un corps de message SOAP. Ce sont: Document & RPC
L'avantage d'utiliser un modèle de style Document est que vous pouvez structurer le corps SOAP comme vous le souhaitez tant que le contenu du corps du message SOAP est une instance XML arbitraire. Le style Document est également appelé style orienté message.
Cependant, avec un modèle de style RPC, la structure du corps de la requête SOAP doit contenir à la fois le nom de l'opération et l'ensemble des paramètres de méthode. Le modèle de style RPC suppose une structure spécifique pour l'instance XML contenue dans le corps du message.
De plus, il existe deux modèles d'utilisation d'encodage qui sont utilisés pour traduire un binding WSDL en un message SOAP. Ce sont: littéral et encodé
Lors de l'utilisation d'un modèle d'utilisation littéral, le contenu du corps doit correspondre à une structure XML-schema(XSD) définie par l'utilisateur. L'avantage est double. Tout d'abord, vous pouvez valider le corps du message avec le XML-schema défini par l'utilisateur, de plus, vous pouvez également transformer le message en utilisant un langage de transformation comme XSLT.
Avec un modèle d'utilisation (SOAP) encodé, le message doit utiliser des types de données XSD, mais la structure du message ne doit pas nécessairement correspondre à un schéma XML défini par l'utilisateur. Cela rend difficile la validation du corps du message ou l'utilisation de transformations basées sur XSLT sur le corps du message.
La combinaison des différents modèles de style et d'utilisation nous donne quatre façons différentes de traduire un binding WSDL en un message SOAP.
Document/littéral
Document/encodé
RPC/littéral
RPC/encodé
Je vous recommande de lire cet article intitulé Quel style de WSDL devrais-je utiliser? par Russell Butek qui offre une belle discussion sur les différents modèles de style et d'utilisation pour traduire un binding WSDL en un message SOAP, et leurs forces et faiblesses respectives.
Une fois que les artefacts sont reçus, dans les deux styles de communication, je invoque la méthode sur le port. Maintenant, cela ne diffère pas dans le style RPC et le style Document. Alors quel est la différence et où est cette différence visible?
L'endroit où vous pouvez trouver la différence est la "RÉPONSE"!
Style RPC:
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
@WebService
@SOAPBinding(style=Style.RPC)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
Le message SOAP pour la deuxième opération aura une sortie vide et ressemblera à:
Réponse de style RPC:
Style Document:
package com.sample;
import java.util.ArrayList;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;
@WebService
@SOAPBinding(style=Style.DOCUMENT)
public interface StockPrice {
public String getStockPrice(String stockName);
public ArrayList getStockPriceList(ArrayList stockNameList);
}
Si nous exécutons le client pour l'interface fournie ci-dessus, la sortie est:
123 [123, 456]
Cette sortie montre que les éléments de ArrayList sont échangés entre le service web et le client. Ce changement a été effectué uniquement en modifiant l'attribut de style de l'annotation SOAPBinding. Le message SOAP pour la deuxième méthode avec un type de données plus riche est affiché ci-dessous à titre de référence:
Réponse de style Document:
123
456
Conclusion
- Comme vous l'avez remarqué dans les deux messages de réponse SOAP, il est possible de valider le message de réponse SOAP dans le cas des services Web de style DOCUMENT mais pas dans les services Web de style RPC.
- Le désavantage principal de l'utilisation du style RPC est qu'il ne supporte pas les types de données plus riches et celui de l'utilisation du style Document est qu'il introduit une certaine complexité sous forme de XSD pour définir les types de données plus riches.
- Le choix entre les deux dépend des besoins de l'opération/méthode et des clients attendus.
De la même manière, en quoi le SOAP sur HTTP diffère-t-il du XML sur HTTP? Après tout, le SOAP est également un document XML avec un espace de noms SOAP. Alors, quelle est la différence ici?
Pourquoi avons-nous besoin d'une norme comme SOAP? En échangeant des documents XML sur HTTP, deux programmes peuvent échanger des informations riches et structurées sans l'introduction d'une norme supplémentaire telle que SOAP pour décrire explicitement un format d'enveloppe de message et un moyen d'encoder le contenu structuré.
SOAP fournit une norme afin que les développeurs n'aient pas à inventer un format de message XML personnalisé pour chaque service qu'ils veulent rendre disponible. Étant donné la signature de la méthode du service à appeler, la spécification SOAP prescrit un format de message XML non ambigu. Tout développeur familier avec la spécification SOAP, travaillant dans n'importe quel langage de programmation, peut formuler une requête SOAP XML correcte pour un service particulier et comprendre la réponse du service en obtenant les détails de services suivants.
- Nom du service
- Noms des méthodes implémentées par le service
- Signature de chaque méthode
- Adresse de l'implémentation du service (exprimée sous forme d'URI)
L'utilisation de SOAP simplifie le processus pour exposer un composant logiciel existant en tant que service Web car la signature de la méthode du service identifie la structure du document XML utilisée à la fois pour la requête et la réponse.
