Qual è la differenza tra lo stile del documento e la comunicazione in stile RPC?


92

Qualcuno può spiegarmi le differenze tra i servizi web in stile Document e RPC? Oltre a JAX-RPC, la prossima versione è JAX-WS, che supporta sia gli stili Document che RPC. Capisco anche che i servizi web in stile documento sono pensati per la comunicazione asincrona in cui un client non si bloccherebbe fino a quando non riceve la risposta.

Ad ogni modo, utilizzando JAX-WS attualmente annoto il servizio con @Webservice , generi il WSDL e da quel WSDL generi gli artefatti lato client.

Una volta ricevuti gli artefatti, in entrambi gli stili, invoco il metodo sul port. Ora, questo non differisce nello stile RPC e nello stile del documento. Allora qual è la differenza e dove è visibile questa differenza?

Allo stesso modo, in che modo SOAP su HTTP differisce da XML su HTTP? Dopo tutto SOAP è anche un documento XML con spazio dei nomi SOAP.


4
possibile duplicato di servizi web basati
skaffman

Risposte:


97

Qualcuno può spiegarmi le differenze tra uno stile documento e servizi web in stile RPC?

Esistono due modelli di stile di comunicazione utilizzati per tradurre un'associazione WSDL in un corpo del messaggio SOAP. Loro sono: Documento e RPC

Il vantaggio dell'utilizzo di un modello di stile del documento è che puoi strutturare il corpo SOAP come preferisci, purché il contenuto del corpo del messaggio SOAP sia un'istanza XML arbitraria. Lo stile del documento viene anche definito stile orientato ai messaggi .

Tuttavia, con un modello di stile RPC , la struttura del corpo della richiesta SOAP deve contenere sia il nome dell'operazione che il set di parametri del metodo. Il modello di stile RPC presuppone una struttura specifica per l' istanza XML contenuta nel corpo del messaggio.

Inoltre, esistono due modelli di utilizzo della codifica utilizzati per tradurre un'associazione WSDL in un messaggio SOAP. Sono: letterali e codificati

Quando si utilizza un modello d'uso letterale , il contenuto del corpo deve essere conforme a una struttura XML-schema (XSD) definita dall'utente . Il vantaggio è duplice. Per prima cosa, puoi convalidare il corpo del messaggio con lo schema XML definito dall'utente, inoltre, puoi anche trasformare il messaggio utilizzando un linguaggio di trasformazione come XSLT.

Con un modello d'uso codificato (SOAP) , il messaggio deve utilizzare i tipi di dati XSD, ma la struttura del messaggio non deve essere conforme a nessuno schema XML definito dall'utente. Ciò rende difficile convalidare il corpo del messaggio o utilizzare trasformazioni basate su XSLT sul corpo del messaggio.

La combinazione dei diversi modelli di stile e utilizzo ci offre quattro modi diversi per tradurre un'associazione WSDL in un messaggio SOAP.

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

Ti consiglio di leggere questo articolo intitolato Quale stile di WSDL dovrei usare? di Russell Butek che ha una bella discussione sul diverso stile e sui modelli di utilizzo per tradurre un binding WSDL in un messaggio SOAP e sui relativi punti di forza e di debolezza.

Una volta ricevuti gli artefatti, in entrambi gli stili di comunicazione, invoco il metodo sulla porta. Ora, questo non differisce nello stile RPC e nello stile del documento. Allora qual è la differenza e dove è visibile questa differenza?

Il luogo dove puoi trovare la differenza è la "RISPOSTA"!

Stile 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); 
}

Il messaggio SOAP per la seconda operazione avrà un output vuoto e sarà simile a:

Risposta in stile RPC:

<ns2:getStockPriceListResponse 
       xmlns:ns2="http://sample.com/">
    <return/>
</ns2:getStockPriceListResponse>
</S:Body>
</S:Envelope>

Stile documento:

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);
}

Se eseguiamo il client per il SEI di cui sopra, l'output è:

123 [123, 456]

Questo output mostra che gli elementi ArrayList vengono scambiati tra il servizio Web e il client. Questa modifica è stata eseguita solo cambiando l'attributo di stile dell'annotazione SOAPBinding. Il messaggio SOAP per il secondo metodo con un tipo di dati più ricco è mostrato di seguito per riferimento:

Risposta in stile documento:

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

Conclusione

  • Come avrete notato nei due messaggi di risposta SOAP che è possibile validare il messaggio di risposta SOAP in caso di stile DOCUMENTO ma non nei servizi web stile RPC.
  • Lo svantaggio fondamentale dell'utilizzo dello stile RPC è che non supporta tipi di dati più ricchi e quello dell'utilizzo dello stile documento è che apporta una certa complessità sotto forma di XSD per la definizione dei tipi di dati più ricchi.
  • La scelta di utilizzare uno di questi dipende dai requisiti di operazione / metodo e dai clienti attesi.

Allo stesso modo, in che modo SOAP su HTTP differisce da XML su HTTP? Dopo tutto SOAP è anche un documento XML con spazio dei nomi SOAP. Allora qual è la differenza qui?

Perché abbiamo bisogno di uno standard come SOAP? Scambiando documenti XML su HTTP, due programmi possono scambiare informazioni ricche e strutturate senza l'introduzione di uno standard aggiuntivo come SOAP per descrivere esplicitamente il formato della busta del messaggio e un modo per codificare il contenuto strutturato.

SOAP fornisce uno standard in modo che gli sviluppatori non debbano inventare un formato di messaggio XML personalizzato per ogni servizio che desiderano rendere disponibile. Data la firma del metodo di servizio da richiamare, la specifica SOAP prescrive un formato di messaggio XML non ambiguo. Qualsiasi sviluppatore che abbia familiarità con la specifica SOAP, lavorando con qualsiasi linguaggio di programmazione, può formulare una richiesta XML SOAP corretta per un particolare servizio e comprendere la risposta dal servizio ottenendo i seguenti dettagli del servizio.

  • Nome di Servizio
  • Nomi dei metodi implementati dal servizio
  • Firma del metodo di ciascun metodo
  • Indirizzo dell'implementazione del servizio (espresso come URI)

L'utilizzo di SOAP semplifica il processo di esposizione di un componente software esistente come servizio Web poiché la firma del metodo del servizio identifica la struttura del documento XML utilizzata sia per la richiesta che per la risposta.


Un ringraziamento speciale per "Quale stile di WSDL dovrei usare?" collegamento dell'articolo.
Boolean_Type


20

Nella definizione WSDL, i collegamenti contengono operazioni, ecco lo stile per ogni operazione.

Documento: nel file WSDL, specifica i dettagli dei tipi che hanno inline o importa un documento XSD, che descrive la struttura (cioè lo schema) dei tipi di dati complessi scambiati da quei metodi di servizio che rendono loosely coupled. Lo stile del documento è quello predefinito.

  • Vantaggio :
    • Utilizzando questo stile di documento, possiamo convalidare i messaggi SOAP rispetto allo schema predefinito. Supporta tipi di dati e modelli xml.
    • debolmente accoppiato.
  • Svantaggio : è un po 'difficile da capire.

Nei tipi WSDL l'elemento appare come segue:

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

Lo schema sta importando da un riferimento esterno.

RPC : Nel file WSDL, non crea schemi di tipi, all'interno degli elementi del messaggio definisce attributi di nome e tipo che rendono strettamente accoppiati.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>  
  • Vantaggio : facile da capire.
  • Svantaggio :
    • non possiamo convalidare i messaggi SOAP.
    • strettamente accoppiati

RPC: nessun tipo nel
documento WSDL : la sezione Tipi sarebbe disponibile in WSDL


Ho appena ripetuto ciò che è nel riferimento. Questa spiegazione non mi ha aiutato a capire la differenza.
Kinunt

1
questo sicuramente non proviene da un riferimento o da una documentazione - è pieno di errori grammaticali
specializzato il

7

Lo scenario principale in cui JAX-WS RPC e lo stile del documento vengono utilizzati come segue:

  • La chiamata di procedura remota (RPC) pattern viene utilizzato quando il consumatore visualizza il servizio Web come una singola applicazione logica o componente con dati incapsulati. I messaggi di richiesta e di risposta vengono mappati direttamente ai parametri di input e output della chiamata di procedura.

    Esempi di questo tipo il modello RPC potrebbe includere un servizio di pagamento o un servizio di quotazione di borsa.

  • Il modello basato sul documento viene utilizzato in situazioni in cui il consumatore vede il servizio Web come un processo aziendale più a lungo in esecuzione in cui il documento di richiesta rappresenta un'unità completa di informazioni. Questo tipo di servizio web può comportare l'interazione umana, ad esempio come con un documento di richiesta di richiesta di credito con un documento di risposta contenente offerte da istituti di credito. Poiché i processi aziendali più in esecuzione potrebbero non essere in grado di restituire immediatamente il documento richiesto, il modello basato sul documento si trova più comunemente nelle architetture di comunicazione asincrone. La variazione documento / letterale di SOAP viene utilizzata per implementare il modello di servizio Web basato su documenti.


3

Penso che quello che stai chiedendo sia la differenza tra i servizi web RPC Literal, Document Literal e Document Wrapped SOAP.

Si noti che i servizi Web di documento sono delineati in letterale e anche impacchettati e sono diversi: una delle differenze principali è che quest'ultimo è conforme a BP 1.1 e il primo no.

Inoltre, in Document Literal l'operazione da richiamare non è specificata in termini di nome mentre in Wrapped lo è. Questa, penso, sia una differenza significativa in termini di capire facilmente il nome dell'operazione a cui è rivolta la richiesta.

In termini di RPC letterale rispetto a Document Wrapped, la richiesta Document Wrapped può essere facilmente controllata / convalidata rispetto allo schema nel WSDL: un grande vantaggio.

Suggerirei di utilizzare Document Wrapped come tipo di servizio Web preferito a causa dei suoi vantaggi.

SOAP su HTTP è il protocollo SOAP associato a HTTP come vettore. SOAP potrebbe essere anche su SMTP o XXX. SOAP fornisce un modo di interazione tra le entità (client e server, ad esempio) ed entrambe le entità possono eseguire il marshalling degli argomenti dell'operazione / restituire valori secondo la semantica del protocollo.

Se stavi utilizzando XML su HTTP (e puoi farlo), è semplicemente inteso come payload XML su richiesta / risposta HTTP. Dovresti fornire il framework per eseguire il marshalling / unmarshal, la gestione degli errori e così via.

Un tutorial dettagliato con esempi di WSDL e codice con enfasi su Java: SOAP e JAX-WS, RPC rispetto a Document Web Services


2

Documento
I messaggi in stile documento possono essere convalidati rispetto allo schema predefinito. Nello stile del documento, il messaggio SOAP viene inviato come un unico documento. Esempio di schema:

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

Esempio di messaggio del corpo del sapone in stile documento

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

Il messaggio in stile documento è vagamente accoppiato.

I messaggi in stile RPC RPC utilizzano il nome del metodo ei parametri per generare la struttura XML. i messaggi sono difficili da convalidare rispetto allo schema. In stile RPC, il messaggio SOAP viene inviato come molti elementi.

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

Qui ogni parametro è specificato in modo discreto, il messaggio in stile RPC è strettamente accoppiato, è tipicamente statico, richiede modifiche al client quando la firma del metodo cambia Lo stile rpc è limitato a tipi XSD molto semplici come String e Integer, e il WSDL risultante non lo farà hanno anche una sezione dei tipi per definire e vincolare i parametri

Letterale Per impostazione predefinita. I dati vengono serializzati in base a uno schema, il tipo di dati non specificato nei messaggi ma viene utilizzato un riferimento allo schema (spazio dei nomi) per creare messaggi soap.

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

Tipo di dati codificato specificato in ogni parametro

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

Schema libero

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.