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.