Was ist der Unterschied zwischen der Kommunikation im Dokumentstil und im RPC-Stil?

Kann mir jemand die Unterschiede zwischen Webservices im Dokument- und RPC-Stil erklären? Neben JAX-RPC ist die nächste Version JAX-WS, die sowohl Dokument- als auch RPC-Stile unterstützt. Ich verstehe auch, dass Webservices im Dokumentstil für die asynchrone Kommunikation gedacht sind, bei der ein Client nicht blockieren würde, bis die Antwort empfangen wird.

In beiden Fällen kommentiere ich mit JAX-WS den Dienst derzeit mit @Webservice , generiere die WSDL und generiere aus dieser WSDL die clientseitigen Artefakte.

Sobald die Artefakte in beiden Stilen empfangen wurden, rufe ich die Methode am Port auf. Dies unterscheidet sich nicht im RPC-Stil und im Dokumentstil. Was ist der Unterschied und wo ist dieser Unterschied sichtbar?

Inwiefern unterscheidet sich SOAP über HTTP von XML über HTTP? Immerhin ist SOAP auch ein XML-Dokument mit SOAP-Namespace.

Kann mir jemand die Unterschiede zwischen Webservices im Dokumentstil und im RPC-Stil erklären?

Es gibt zwei Kommunikationsstilmodelle, mit denen eine WSDL-Bindung in einen SOAP-Nachrichtentext übersetzt wird. Sie sind: Dokument & RPC

Der Vorteil der Verwendung eines Dokumentstilmodells besteht darin, dass Sie den SOAP-Text nach Belieben strukturieren können, solange der Inhalt des SOAP-Nachrichtentexts eine beliebige XML-Instanz ist. Der Dokumentstil wird auch als nachrichtenorientierter Stil bezeichnet .

Bei einem Modell im RPC-Stil muss die Struktur des SOAP-Anforderungshauptteils jedoch sowohl den Operationsnamen als auch den Satz von Methodenparametern enthalten. Das RPC-Stilmodell nimmt eine bestimmte Struktur für die im Nachrichtentext enthaltene XML-Instanz an.

Darüber hinaus gibt es zwei Modelle zur Verwendung der Codierung, mit denen eine WSDL-Bindung in eine SOAP-Nachricht übersetzt wird. Sie sind: wörtlich und verschlüsselt

Bei Verwendung eines Literal-Use-Modells sollte der Inhalt des Körpers einer benutzerdefinierten XSD-Struktur (XML-Schema) entsprechen . Der Vorteil ist zweifach. Zum einen können Sie den Nachrichtentext mit dem benutzerdefinierten XML-Schema validieren. Darüber hinaus können Sie die Nachricht auch mit einer Transformationssprache wie XSLT transformieren.

Bei einem (SOAP) -codierten Verwendungsmodell muss die Nachricht XSD-Datentypen verwenden, die Struktur der Nachricht muss jedoch keinem benutzerdefinierten XML-Schema entsprechen. Dies macht es schwierig, den Nachrichtentext zu validieren oder XSLT-basierte Transformationen für den Nachrichtentext zu verwenden.

Die Kombination der verschiedenen Stil- und Verwendungsmodelle bietet uns vier verschiedene Möglichkeiten, eine WSDL-Bindung in eine SOAP-Nachricht zu übersetzen.

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

Ich würde empfehlen, dass Sie diesen Artikel mit dem Titel Welchen WSDL-Stil soll ich lesen ? von Russell Butek, der eine schöne Diskussion über die verschiedenen Stile und die Verwendung von Modellen zur Übersetzung einer WSDL-Bindung in eine SOAP-Nachricht sowie deren relative Stärken und Schwächen hat.

Sobald die Artefakte empfangen wurden, rufe ich in beiden Kommunikationsstilen die Methode am Port auf. Dies unterscheidet sich nicht im RPC-Stil und im Dokumentstil. Was ist der Unterschied und wo ist dieser Unterschied sichtbar?

Der Ort, an dem Sie den Unterschied finden können, ist die "ANTWORT"!

RPC-Stil:

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

Die SOAP-Nachricht für die zweite Operation hat eine leere Ausgabe und sieht folgendermaßen aus:

Antwort im RPC-Stil:

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

Dokumentstil:

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

Wenn wir den Client für die obige SEI ausführen, lautet die Ausgabe:

123 [123, 456]

Diese Ausgabe zeigt, dass ArrayList-Elemente zwischen dem Webdienst und dem Client ausgetauscht werden. Diese Änderung wurde nur durch Ändern des Stilattributs der SOAPBinding-Annotation vorgenommen. Die SOAP-Nachricht für die zweite Methode mit einem umfangreicheren Datentyp wird unten als Referenz angezeigt:

Antwort auf den Dokumentstil:

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

Fazit

• Wie Sie in den beiden SOAP-Antwortnachrichten bemerkt haben, ist es möglich, die SOAP-Antwortnachricht im Falle eines DOCUMENT-Stils zu validieren, jedoch nicht in Webdiensten im RPC-Stil.
• Der grundlegende Nachteil der Verwendung des RPC-Stils besteht darin, dass keine umfangreicheren Datentypen unterstützt werden, und dass die Verwendung des Dokumentstils darin besteht, dass die Definition der umfangreicheren Datentypen eine gewisse Komplexität in Form von XSD mit sich bringt.
• Die Wahl einer dieser Optionen hängt von den Betriebs- / Methodenanforderungen und den erwarteten Clients ab.

Inwiefern unterscheiden sich SOAP über HTTP von XML über HTTP? Immerhin ist SOAP auch ein XML-Dokument mit SOAP-Namespace. Was ist hier der Unterschied?

Warum brauchen wir einen Standard wie SOAP? Durch den Austausch von XML-Dokumenten über HTTP können zwei Programme umfangreiche strukturierte Informationen austauschen, ohne einen zusätzlichen Standard wie SOAP einzuführen, um ein Nachrichtenumschlagformat explizit zu beschreiben und strukturierte Inhalte zu codieren.

SOAP bietet einen Standard, damit Entwickler nicht für jeden Dienst, den sie zur Verfügung stellen möchten, ein benutzerdefiniertes XML-Nachrichtenformat erfinden müssen. Angesichts der Signatur der aufzurufenden Dienstmethode schreibt die SOAP-Spezifikation ein eindeutiges XML-Nachrichtenformat vor. Jeder Entwickler, der mit der SOAP-Spezifikation vertraut ist und in einer beliebigen Programmiersprache arbeitet, kann eine korrekte SOAP-XML-Anforderung für einen bestimmten Dienst formulieren und die Antwort des Dienstes verstehen, indem er die folgenden Dienstdetails abruft.

• Dienstname
• Vom Dienst implementierte Methodennamen
• Methodensignatur jeder Methode
• Adresse der Service-Implementierung (ausgedrückt als URI)

Die Verwendung von SOAP optimiert den Prozess zum Bereitstellen einer vorhandenen Softwarekomponente als Webdienst, da die Methodensignatur des Dienstes die XML-Dokumentstruktur identifiziert, die sowohl für die Anforderung als auch für die Antwort verwendet wird.

Ein Webdienst im RPC-Stil verwendet die Namen der Methode und ihre Parameter, um XML-Strukturen zu generieren, die den Aufrufstapel einer Methode darstellen. Der Dokumentstil gibt an, dass der SOAP-Body ein XML-Dokument enthält, das anhand eines vordefinierten XML-Schemadokuments validiert werden kann.

Ein guter Ausgangspunkt: SOAP-Bindung: Unterschied zwischen Dokument- und RPC-Webdiensten

In der WSDL-Definition enthalten Bindungen Operationen. Hier kommt der Stil für jede Operation.

Dokument: In der WSDL-Datei werden Typdetails angegeben, die entweder ein Inline- oder ein XSD-Dokument importieren. Dieses beschreibt die Struktur (dh das Schema) der komplexen Datentypen, die von den Dienstmethoden ausgetauscht werden, die eine lose Kopplung herstellen. Der Dokumentstil ist Standard.

• Vorteil :
  • Mit diesem Dokumentstil können wir SOAP-Nachrichten anhand eines vordefinierten Schemas validieren. Es unterstützt XML-Datentypen und -Muster.
  • locker verbunden.
• Nachteil : Es ist ein bisschen schwer zu verstehen.

In WSDL-Typen sieht das Element wie folgt aus:

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

Das Schema wird aus einer externen Referenz importiert.

RPC : In einer WSDL-Datei wird kein Typschema erstellt, sondern innerhalb von Nachrichtenelementen werden Name- und Typattribute definiert, wodurch eine enge Kopplung hergestellt wird.

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

• Vorteil : Leicht zu verstehen.
• Nachteil :
  • Wir können keine SOAP-Nachrichten validieren.
  • eng verbunden

RPC: In WSDL sind keine Typen verfügbar. Der Abschnitt
Dokumente: Typen ist in WSDL verfügbar

Das Hauptszenario, in dem JAX-WS RPC und Dokumentstil wie folgt verwendet werden:

• Das RPC- Muster (Remote Procedure Call) wird verwendet, wenn der Verbraucher den Webdienst als eine einzelne logische Anwendung oder Komponente mit gekapselten Daten betrachtet. Die Anforderungs- und Antwortnachrichten werden direkt den Eingabe- und Ausgabeparametern des Prozeduraufrufs zugeordnet.

  Beispiele für diesen Typ des RPC-Musters können einen Zahlungsservice oder einen Börsenkursdienst umfassen.

• Das dokumentbasierte Muster wird in Situationen verwendet, in denen der Verbraucher den Webdienst als einen länger laufenden Geschäftsprozess betrachtet, in dem das Anforderungsdokument eine vollständige Informationseinheit darstellt. Diese Art von Webdienst kann eine menschliche Interaktion beinhalten, beispielsweise wie bei einem Kreditantragsanforderungsdokument mit einem Antwortdokument, das Angebote von Kreditinstituten enthält. Da länger laufende Geschäftsprozesse das angeforderte Dokument möglicherweise nicht sofort zurückgeben können, ist das dokumentbasierte Muster in asynchronen Kommunikationsarchitekturen häufiger anzutreffen. Die Document / Literal-Variante von SOAP wird verwendet, um das dokumentbasierte Webdienstmuster zu implementieren.

Ich denke, was Sie fragen, ist der Unterschied zwischen RPC Literal-, Document Literal- und Document Wrapped SOAP-Webdiensten.

Beachten Sie, dass Document-Webdienste in Literal abgegrenzt und ebenfalls verpackt sind und sich unterscheiden. Einer der Hauptunterschiede besteht darin, dass letztere BP 1.1-kompatibel sind und erstere nicht.

Außerdem wird in Document Literal die aufzurufende Operation nicht in Bezug auf ihren Namen angegeben, während dies in Wrapped der Fall ist. Ich denke, dies ist ein wesentlicher Unterschied in Bezug auf die einfache Ermittlung des Operationsnamens, für den die Anforderung bestimmt ist.

In Bezug auf RPC-Literal im Vergleich zu Document Wrapped kann die Document Wrapped-Anforderung leicht anhand des Schemas in der WSDL überprüft / validiert werden - ein großer Vorteil.

Ich würde vorschlagen, Document Wrapped aufgrund seiner Vorteile als Webdiensttyp der Wahl zu verwenden.

SOAP auf HTTP ist das SOAP-Protokoll, das als Träger an HTTP gebunden ist. SOAP kann auch über SMTP oder XXX sein. SOAP bietet eine Möglichkeit zur Interaktion zwischen Entitäten (z. B. Client und Server), und beide Entitäten können Operationsargumente / Rückgabewerte gemäß der Semantik des Protokolls zusammenstellen.

Wenn Sie XML über HTTP verwendet haben (und dies können), wird dies einfach als XML-Nutzlast bei HTTP-Anforderung / Antwort verstanden. Sie müssten das Framework für Marschall / Unmarschall, Fehlerbehandlung usw. bereitstellen.

Ein detailliertes Tutorial mit Beispielen für WSDL und Code mit Schwerpunkt auf Java: SOAP und JAX-WS, RPC versus Document Web Services

Dokument
Nachrichten im Dokumentstil können anhand eines vordefinierten Schemas überprüft werden. Im Dokumentstil wird die SOAP-Nachricht als einzelnes Dokument gesendet. Beispiel für ein Schema:

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

Beispiel einer Seifenkörpernachricht im Dokumentstil

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

Die Nachricht im Dokumentstil ist lose gekoppelt.

RPC Nachrichten im RPC-Stil verwenden Methodennamen und Parameter, um eine XML-Struktur zu generieren. Nachrichten sind schwer anhand des Schemas zu validieren. Im RPC-Stil wird eine SOAP-Nachricht mit so vielen Elementen gesendet.

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

Hier werden die einzelnen Parameter diskret angegeben. Die Nachricht im RPC-Stil ist eng gekoppelt, normalerweise statisch und erfordert Änderungen am Client, wenn sich die Methodensignatur ändert. Der RPC-Stil ist auf sehr einfache XSD-Typen wie String und Integer beschränkt, die resultierende WSDL jedoch nicht Es gibt sogar einen Typabschnitt zum Definieren und Einschränken der Parameter

Literal Standardmäßig Stil. Die Daten werden gemäß einem Schema serialisiert. Der Datentyp wird nicht in Nachrichten angegeben, aber ein Verweis auf das Schema (Namespace) wird zum Erstellen von Seifennachrichten verwendet.

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

In jedem Parameter angegebener codierter Datentyp

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

Schema frei