Un organisme peut-il m'expliquer les différences entre un style de document et des services Web de style RPC?
Il existe deux modèles de style de communication utilisés pour traduire une liaison WSDL en corps de message SOAP. Ce sont:
Document & RPC
L' avantage d'utiliser un modèle de style de document est que vous pouvez structurer le corps SOAP comme vous le souhaitez, à condition que le contenu du corps du message SOAP soit une instance XML arbitraire. Le style de 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 à l' instance XML contenue dans le corps du message.
En outre, il existe deux modèles d'utilisation de codage qui sont utilisés pour traduire une liaison WSDL en un message SOAP. Ils sont: littéraux et codés
Lors de l'utilisation d'un modèle d'utilisation littéral , le contenu du corps doit être conforme à une structure XML-schema (XSD) définie par l'utilisateur . L'avantage est double. D'une part, vous pouvez valider le corps du message avec le schéma XML 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 codé (SOAP) , le message doit utiliser des types de données XSD, mais la structure du message n'a pas besoin de se conformer à 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 styles et modèles d'utilisation nous donne quatre manières différentes de traduire une liaison WSDL en message SOAP.
Document/literal
Document/encoded
RPC/literal
RPC/encoded
Je vous recommande de lire cet article intitulé Quel style de WSDL dois-je utiliser? par Russell Butek qui a une belle discussion sur les différents styles et modèles d'utilisation pour traduire une liaison WSDL en un message SOAP, ainsi que leurs forces et faiblesses relatives.
Une fois les artefacts reçus, dans les deux styles de communication, j'invoque la méthode sur le port. Maintenant, cela ne diffère pas dans le style RPC et le style de document. Alors, quelle est la différence et où cette différence est-elle 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 à ceci:
Réponse de style RPC:
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
Style de 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 le SEI ci-dessus, le résultat est:
123 [123, 456]
Cette sortie montre que les éléments ArrayList sont échangés entre le service Web et le client. Cette modification a été effectuée uniquement par la modification de l'attribut style de l'annotation SOAPBinding. Le message SOAP pour la deuxième méthode avec un type de données plus riche est indiqué ci-dessous pour référence:
Réponse du style de document:
<ns2:getStockPriceListResponse
xmlns:ns2="http://sample.com/">
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">123</return>
<return xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xsi:type="xs:string">456</return>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>
Conclusion
- Comme vous l'auriez remarqué dans les deux messages de réponse SOAP, il est possible de valider le message de réponse SOAP en cas de style DOCUMENT mais pas dans les services Web de style RPC.
- L' inconvénient fondamental de l'utilisation du style RPC est qu'il ne prend pas en charge les types de données plus riches et celui de l'utilisation du style Document est qu'il apporte une certaine complexité sous la forme de XSD pour définir les types de données plus riches.
- Le choix d'en utiliser un dépend des exigences de l'opération / de la méthode et des clients attendus.
De même, en quoi SOAP sur HTTP diffère-t-il de XML sur HTTP? Après tout, 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 via 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 de coder un 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 souhaitent rendre disponible. Compte tenu de la signature de la méthode de service à appeler, la spécification SOAP prescrit un format de message XML sans ambiguïté. Tout développeur familiarisé 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 service suivants.
- Nom du service
- Noms de méthodes implémentés par le service
- Signature de méthode de chaque méthode
- Adresse de l'implémentation du service (exprimée sous forme d'URI)
L'utilisation de SOAP rationalise le processus d'exposition d'un composant logiciel existant en tant que service Web, car la signature de méthode du service identifie la structure de document XML utilisée à la fois pour la demande et la réponse.