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 à une communication asynchrone où un client ne bloquerait pas tant que la réponse ne serait pas reçue.

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

Une fois les artefacts reçus, dans les deux styles, 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?

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.

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.

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

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 types de détails ayant soit un document en ligne, soit 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 rend le couplage lâche. Le style de document est le style par défaut.

• Avantage :
  • En utilisant ce style de document, nous pouvons valider les messages SOAP par rapport à un schéma prédéfini. Il prend en charge les types de données et les modèles xml.
  • 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é à partir d'une référence externe.

RPC : Dans le fichier WSDL, il ne crée pas de schéma de types, dans les éléments de message, il définit les attributs de nom et de type qui les rendent étroitement couplés.

<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 le
document WSDL : la section Types serait disponible dans WSDL

Le scénario principal dans lequel JAX-WS RPC et le style de document sont utilisés comme suit:

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

  Des exemples de ce type de modèle RPC peuvent inclure un service de paiement ou un service de cotation boursière.

• Le modèle basé sur un document est utilisé dans les situations où le consommateur considère le service Web comme un processus métier plus long où le document de demande représente une unité complète d'informations. Ce type de service Web peut impliquer une interaction humaine, par exemple avec un document de demande de crédit avec un document de réponse contenant des offres des établissements de crédit. Étant donné que les processus métier plus longs peuvent ne pas être en mesure de renvoyer immédiatement le document demandé, le modèle basé sur le document se trouve plus couramment dans les architectures de communication asynchrones. La variante Document / littéral de SOAP est utilisée pour implémenter le modèle de service Web basé sur un document.

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

Notez que les services Web de document sont délimités en littéral et encapsulés également et qu'ils sont différents - l'une des principales différences est que ce dernier est conforme à BP 1.1 et le premier ne l'est pas.

De plus, dans Document Literal, l'opération à invoquer n'est pas spécifiée en termes de nom alors que dans Wrapped, elle l'est. Cela, je pense, est une différence significative en termes de détermination facile du nom de l'opération à laquelle la demande est destinée.

En termes de littéral RPC par rapport à Document Wrapped, la demande Document Wrapped peut être facilement vérifiée / validée par rapport au schéma dans le WSDL - un gros avantage.

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

SOAP sur HTTP est le protocole SOAP lié à HTTP en tant que transporteur. SOAP peut é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 rassembler des arguments d'opération / renvoyer des valeurs selon 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 de code avec un accent sur Java: SOAP et JAX-WS, RPC versus Document Web Services

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 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é.

Les messages de style RPC RPC utilisent le nom de la méthode et les 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é en autant d'é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 discrète, le message de style RPC est étroitement couplé, est généralement statique, nécessitant des modifications pour le client lorsque la signature de la méthode change Le style rpc est limité aux types XSD très simples tels que String et Integer, et le WSDL résultant ne sera pas même avoir une section types pour définir et contraindre les paramètres

Littéral Par défaut style. 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 au schéma (espace de noms) est utilisée pour construire des messages soap.

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

Type de données codé 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>

Sans schéma