web-dev-qa-db-fra.com

Quelle est la différence entre le style de document et la communication de style RPC?

Quelqu'un peut-il m'expliquer les différences entre les services Web de style Document et RPC? Outre JAX-RPC, la prochaine version est JAX-WS, qui prend en charge les styles Document et RPC. Je comprends également que les services Web de style document sont destinés à la communication asynchrone dans laquelle un client ne pourrait pas bloquer avant la réception de la réponse.

Quoi qu'il en soit, en utilisant JAX-WS, j'annote actuellement le service avec @ Webservice, générez le WSDL et, à partir de ce WSDL, les artefacts côté client.

Une fois les artefacts reçus, dans les deux styles, j'appelle la méthode sur le port. Maintenant, cela ne diffère pas dans le style RPC et le style du document. Alors, quelle est la différence et où cette différence est-elle visible?

De même, en quoi SOAP sur HTTP diffère-t-il de XML sur HTTP?)? SOAP est aussi un document XML avec SOAP = espace de noms.

web-servicessoapwsdljax-wsrpc
87
Amrin

Quelqu'un peut-il m'expliquer les différences entre un service Web de style Document et un style Web RPC?

Deux modèles de style de communication sont utilisés pour convertir une liaison WSDL en un corps de message SOAP. Ils sont: Document & RPC

L'avantage d'utiliser un modèle de style Document est que vous pouvez structurer le corps SOAP comme bon vous semble, aussi longtemps que vous le souhaitez. car le contenu du message SOAP est une instance XML quelconque. Le style du 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 le nom de l'opération]. ensemble de paramètres de méthode. Le modèle de style RPC suppose une structure spécifique au instance XML contenue dans le corps du message.

En outre, deux modèles d’utilisation de l’encodage sont utilisés pour convertir une liaison WSDL en un message SOAP. Ils sont: littéraux et encodés

Lors de l'utilisation d'un modèle d'utilisation littérale , le contenu du corps doit être conforme à un schéma XML (XSD) défini par l'utilisateur . structure . 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 tel que XSLT.

Avec un modèle d'utilisation codé , le message doit utiliser les types de données XSD, mais sa structure ne doit pas nécessairement être conforme à un code XML défini par l'utilisateur. schéma. 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 styles différents et des modèles d'utilisation nous offre quatre façons différentes de traduire une liaison WSDL en un message SOAP.

Document/literal
Document/encoded
RPC/literal
RPC/encoded

Je vous recommanderais de lire cet article intitulé Quel style de WSDL devrais-je utiliser? de Russell Butek, qui a une bonne discussion sur les différents styles et utilise des modèles pour traduire une liaison WSDL en SOAP et leurs forces et faiblesses relatives.

Une fois les artefacts reçus, dans les deux styles de communication, j'appelle la méthode sur le port. Maintenant, cela ne diffère pas dans le style RPC et le style du 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 le suivant:

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 en modifiant l'attribut de style de l'annotation SOAPBinding. Le message SOAP de la deuxième méthode avec un type de données plus riche est présenté ci-dessous à titre de 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 dans le cas du style DOCUMENT mais pas dans le style Web RPC). prestations de service.
  • 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 que l’utilisation du style de document est qu’il apporte une certaine complexité à la forme. de XSD pour définir les types de données les plus riches.
  • Le choix d'utiliser l'un d'entre eux 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 de XML sur HTTP? Après tout SOAP est aussi un document XML avec SOAP espace de noms. 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 de coder un contenu structuré.

SOAP fournit une norme qui évite aux développeurs d'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 non ambigu. Tous les développeurs familiarisés avec la spécification SOAP, langage de programmation, peut formuler une requête XML correcte SOAP 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
  • Méthode signature de chaque méthode
  • Adresse de la mise en œuvre du service (exprimée sous forme d'URI)

L'utilisation de SOAP simplifie le processus permettant d'exposer un composant logiciel existant en tant que service Web, car la signature de la méthode du service identifie la structure de document XML utilisée pour la demande et la réponse.

91
09Q71AO534

Un service Web de style RPC utilise les noms de la méthode et ses paramètres pour générer des structures XML représentant la pile d’appels d’une méthode. Le style de document indique que le corps SOAP contient un document XML qui peut être validé par rapport à un document de schéma XML prédéfini.

Un bon point de départ: Liaison SOAP: Différence entre les services Web de style Document et RPC

23
Binu George

Dans la définition WSDL, les liaisons contiennent des opérations, voici le style pour chaque opération.

Document: Dans le fichier WSDL, il spécifie les détails des types, soit en ligne, soit en important un document XSD, qui décrit la structure (c'est-à-dire, le schéma) des types de données complexes échangés par ces méthodes de service, ce qui permet un couplage faible. Le style du document est par défaut.

  • Avantage :
    • En utilisant ce style de document, nous pouvons valider les messages SOAP contre un schéma prédéfini. Il prend en charge les types de données xml et les modèles.
    • couplage lâche.
  • Inconvénient : C'est un peu difficile à comprendre.

Dans les types WSDL, l'élément se présente comme suit:

<types>
 <xsd:schema>
  <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/>
 </xsd:schema>
</types>

Le schéma est importé depuis une référence externe.

RPC : Dans un fichier WSDL, il ne crée pas de schéma de types. Dans les éléments de message, il définit les attributs name et type qui permettent un couplage étroit.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>
  • Avantage : Facile à comprendre.
  • Inconvénient :
    • nous ne pouvons pas valider les messages SOAP.
    • couplage étroit

RPC: Aucun type dans WSDL
Document: La section Types serait disponible en WSDL

17
Premraj

Le scénario principal dans lequel les styles JAX-WS RPC et Document sont utilisés comme suit:

  • Le modèle appel de procédure distante (RPC) est utilisé lorsque le consommateur considère le service Web comme une seule application logique ou un seul composant avec des données encapsulées. Les messages de demande et de réponse mappent directement les paramètres d'entrée et de sortie de l'appel de procédure.

    Des exemples de ce type, le modèle RPC peuvent inclure un service de paiement ou un service de cotation d’actions.

  • Le modèle basé sur le document est utilisé dans les situations où le consommateur considère le service Web comme un processus technique plus long, dans lequel le document de demande représente une unité complète d'informations. Ce type de service Web peut impliquer une interaction humaine pour exemple comme avec un document de demande de crédit avec un document de réponse contenant des offres émanant d’institutions prêteuses. Étant donné que les processus métier ayant une durée d'exécution plus longue peuvent ne pas être en mesure de renvoyer immédiatement le document demandé, le modèle basé sur le document est plus communément trouvé dans les architectures de communication asynchrones. La variation document/littérale de SOAP est utilisée pour implémenter le modèle de service Web basé sur des documents.

7
Tarun Chaudhary

Je pense que ce que vous demandez, c’est la différence entre les services Web RPC Literal, Document Literal et Document Wrapped SOAP.

Notez que les services Web de document sont définis littéralement et encapsulés de manière différente. Une des principales différences est que le dernier est conforme à BP 1.1 et que le premier ne l’est pas.

En outre, dans Document Literal, l'opération à appeler n'est pas spécifiée en termes de nom mais, dans Wrapped, elle l'est. Je pense que cela constitue une différence importante en termes de détermination du nom de l'opération à laquelle la demande s'adresse.

En termes de littéral RPC par rapport à Document Wrapped, la requête Document Wrapped peut être facilement validée/validée par rapport au schéma du WSDL - un gros avantage.

Je suggérerais d'utiliser Document Wrapped comme type de service Web, en raison de ses avantages.

SOAP sur HTTP est le protocole SOAP lié à HTTP en tant que transporteur. SOAP pourrait également être sur SMTP ou XXX. SOAP fournit un moyen d'interaction entre les entités (client et serveurs, par exemple) et les deux entités peuvent marshaler les arguments/valeurs d'opération conformément à la sémantique du protocole.

Si vous utilisiez XML sur HTTP (et vous le pouvez), il s'agit simplement d'une charge utile XML sur une requête/réponse HTTP. Vous auriez besoin de fournir le cadre pour marshal/unmarshal, la gestion des erreurs, etc.

Un tutoriel détaillé avec des exemples de WSDL et du code mettant l'accent sur Java: SOAP et JAX-WS, RPC par rapport aux services Web de document

3
Khanna111

Document
Les messages de style de document peuvent être validés par rapport à un schéma prédéfini. Dans le style de document, le message SOAP est envoyé sous la forme d'un document unique. Exemple de schéma:

  <types>  
   <xsd:schema> <xsd:import namespace="http://example.com/" 
    schemaLocation="http://localhost:8080/ws/hello?xsd=1"/>  
   </xsd:schema>  
  </types>

Exemple de message de corps de savon de style de document

  <message name="getHelloWorldAsString">   
     <part name="parameters" element="tns:getHelloWorldAsString"/>   
  </message> 
  <message name="getHelloWorldAsStringResponse">  
     <part name="parameters"> element="tns:getHelloWorldAsStringResponse"/>   
  </message>

Le message de style de document est faiblement couplé.

RPC Les messages de style RPC utilisent le nom de la méthode et des paramètres pour générer la structure XML. les messages sont difficiles à valider par rapport au schéma. Dans le style RPC, le message SOAP est envoyé sous forme de nombreux éléments.

  <message name="getHelloWorldAsString">
    <part name="arg0"> type="xsd:string"/>   
   </message> 
  <message name="getHelloWorldAsStringResponse">   
    <part name="return"
   > type="xsd:string"/>   
  </message>

Ici, chaque paramètre est spécifié de manière distincte, le message de style RPC est étroitement lié, il est généralement statique, ce qui nécessite des modifications pour le client lorsque la signature de la méthode change. même avoir une section types pour définir et contraindre les paramètres

Littéral Par défaut. Les données sont sérialisées selon un schéma. Le type de données n'est pas spécifié dans les messages, mais une référence à un schéma (espace de nom) est utilisée pour créer des messages soap.

   <soap:body>
     <myMethod>
        <x>5</x>
        <y>5.0</y>
     </myMethod>
   </soap:body>

codé Type de données spécifié dans chaque paramètre

   <soap:body>
     <myMethod>
         <x xsi:type="xsd:int">5</x>
         <y xsi:type="xsd:float">5.0</y>
     </myMethod>
   </soap:body>

Schéma gratuit

1
Sumant Pandey