Frage Was ist der Unterschied zwischen Dokumentenstil und RPC-Stil-Kommunikation?


Kann mir jemand die Unterschiede zwischen den Webdiensten von Document und RPC erklären? Abgesehen von JAX-RPC ist die nächste Version JAX-WS, die sowohl Document- als auch RPC-Stile unterstützt. Ich verstehe auch, dass Webservices für Dokumentenstil für die asynchrone Kommunikation gedacht sind, bei der ein Client nicht blockiert, bis die Antwort empfangen wird.

Wie auch immer, mit JAX-WS beschreibe ich den Service momentan mit @Internetservice, erzeuge die WSDL und von dieser WSDL erzeuge ich die clientseitigen Artefakte.

Sobald die Artefakte empfangen wurden, rufe ich in beiden Stilen die Methode für den Port auf. Jetzt unterscheidet sich dies nicht in RPC-Stil und Dokument-Stil. Was ist der Unterschied und wo ist dieser Unterschied sichtbar?

In welcher Weise unterscheidet sich SOAP über HTTP von XML über HTTP? Immerhin ist SOAP auch XML-Dokument mit SOAP-Namespace.


76
2018-01-30 10:31


Ursprung


Antworten:


Kann mir ein Körper die Unterschiede zwischen einem Dokumentstil und   RPC-Stil Webservices?

Es gibt zwei Kommunikationsstilmodelle, die zum Übersetzen einer WSDL-Bindung in einen SOAP-Nachrichtentext verwendet werden. Sie sind:   Dokument und RPC

Das Vorteil der Verwendung eines Document-Style-Modells Sie können den SOAP-Body beliebig strukturieren, solange der Inhalt des SOAP-Nachrichtentexts eine beliebige XML-Instanz ist. Der Dokumentstil wird auch als bezeichnet Nachrichtenorientierter Stil.

Jedoch mit einem RPC-Stilmodell, Die Struktur des SOAP-Request-Body muss sowohl den Operationsnamen als auch die Menge der Methodenparameter enthalten. Das RPC - Stilmodell geht von einer spezifischen Struktur aus XML-Instanz im Nachrichtentext enthalten.

Darüber hinaus gibt es zwei Codierungsverwendungsmodelle, die zum Übersetzen einer WSDL-Bindung in eine SOAP-Nachricht verwendet werden. Sie sind: wörtlich und codiert

Bei Verwendung eines wörtliches Verwendungsmodell, sollte der Körperinhalt einem benutzerdefinierten entsprechen XML-Schema (XSD) Struktur. Der Vorteil ist zweifach. Zum einen können Sie den Nachrichtentext mit dem benutzerdefinierten XML-Schema validieren, außerdem können Sie die Nachricht auch mit einer Transformationssprache wie XSLT transformieren.

Mit einem (SOAP) codiertes Nutzungsmodell, die Nachricht muss XSD-Datentypen verwenden, aber die Struktur der Nachricht muss nicht mit einem benutzerdefinierten XML-Schema übereinstimmen. Dies erschwert die Validierung des Nachrichtentexts oder die Verwendung von XSLT-basierten Transformationen für den Nachrichtentext.

Die Kombination der verschiedenen Stil- und Verwendungsmodelle gibt 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 lesen Welchen WSDL-Stil sollte ich verwenden? von Russell Butek, der eine nette Diskussion über den unterschiedlichen Stil führt und Modelle verwendet, um eine WSDL-Bindung an eine SOAP-Nachricht und ihre relativen Stärken und Schwächen zu übersetzen.

Sobald die Artefakte empfangen wurden, habe ich in beiden Kommunikationsstilen   Rufen Sie die Methode für den Port auf. Dies unterscheidet sich im RPC-Stil nicht   und Dokumentstil. Was ist der Unterschied und wo ist das?   Unterschied sichtbar?

Der Ort, wo Sie den Unterschied finden können, ist die "RESPONSE"!

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:

RPC-Stil Antwort:

<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 den obigen SEI ausführen, lautet die Ausgabe:

123 [123, 456]

Diese Ausgabe zeigt, dass ArrayList-Elemente zwischen dem Web-Service 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 reicherem Datentyp wird unten als Referenz angezeigt:

Dokumentstil Antwort:

<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 zwei SOAP-Antwortnachrichten bemerkt haben, ist es möglich, die SOAP-Antwortnachricht im Fall von DOCUMENT-Format, aber nicht in RPC-Webdiensten zu überprüfen.
  • Das Grundlegende Nachteil der Verwendung von RPC-Stil ist das nicht Unterstützung reichere Datentypen und die Verwendung von Document-Stil ist, dass es bringt eine gewisse Komplexität in Form von XSD für die Definition der Reicher Datentypen.
  • Die Wahl der Verwendung eines davon hängt von der Operation / Methode Anforderungen und die erwarteten Kunden.

In welcher Weise unterscheidet sich SOAP über HTTP von XML über HTTP? Nach   Alle SOAP sind auch XML-Dokumente mit SOAP-Namespace. Also was ist das?   Unterschied hier?

Warum brauchen wir einen Standard wie SOAP? Durch den Austausch von XML-Dokumenten über HTTP können zwei Programme umfangreiche, strukturierte Informationen ohne die Einführung eines zusätzlichen Standards wie SOAP austauschen, um ein Format für Nachrichtenumschläge und eine Möglichkeit zum Verschlüsseln von strukturiertem Inhalt zu beschreiben.

SOAP bietet einen Standard, sodass Entwickler kein benutzerdefiniertes XML-Nachrichtenformat für jeden Dienst erfinden müssen, den sie bereitstellen möchten. Mit 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 erhält.

  • Dienstname
  • Methodennamen, die vom Service implementiert werden
  • Methodensignatur jeder Methode
  • Adresse der Service-Implementierung (ausgedrückt als URI)

Durch die Verwendung von SOAP wird der Prozess zur Darstellung einer vorhandenen Softwarekomponente als Web-Service rationalisiert, da die Methodensignatur des Service die XML-Dokumentstruktur identifiziert, die sowohl für die Anforderung als auch für die Antwort verwendet wird.


81
2018-02-04 13:23



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

Ein guter Ausgangspunkt: SOAP Binding: Unterschied zwischen Document und RPC Style Web Services


21
2018-05-20 09:07



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

Dokument: In der WSDL-Datei gibt sie Typendetails an, die entweder ein Inline- oder importiertes XSD-Dokument haben, das die Struktur (d. H. Das Schema) der komplexen Datentypen beschreibt, die von diesen Dienstmethoden ausgetauscht werden, die lose gekoppelt sind. 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 importiert von externer Referenz.

RPC : In der WSDL-Datei wird kein Typschema erstellt, innerhalb von Nachrichtenelementen definiert sie Attribute für Name und Typ, die eng gekoppelt sind.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>  
  • Vorteil: Einfach zu verstehen.
  • Nachteil:
    • Wir können SOAP-Nachrichten nicht validieren.
    • eng verbunden

RPC: Keine Typen in WSDL
Dokument: Der Abschnitt "Typen" wäre in WSDL verfügbar


14
2018-02-09 10:23



Das Hauptszenario wo JAX-WS RPC und Dokument Stil wird wie folgt verwendet:

  • Das Remoteprozeduraufruf (RPC) Das Muster wird verwendet, wenn der Benutzer den Web-Service als eine einzelne logische Anwendung oder Komponente mit gekapselten Daten betrachtet. Die Anfrage- und Antwortnachrichten ordnen sich direkt den Eingabe- und Ausgabeparametern des Prozeduraufrufs zu.

    Beispiele für diesen Typ des RPC-Musters können ein Zahlungsdienst oder ein Aktienangebotsdienst sein.

  • Das Dokument-basierte Muster wird in Situationen verwendet, in denen der Konsument den Webdienst als länger laufenden Geschäftsprozess betrachtet, in dem das Anforderungsdokument eine vollständige Informationseinheit darstellt. Diese Art von Web-Service kann menschliche Interaktion für beinhalten Beispiel wie bei einem Kreditantragsantrag mit einem Antwortdokument, das Gebote von Kreditinstituten enthält. Da länger laufende Geschäftsprozesse möglicherweise nicht in der Lage sind, das angeforderte Dokument sofort zurückzugeben, wird das dokumentenbasierte Muster häufiger in asynchronen Kommunikationsarchitekturen gefunden. Die Document / Literal-Variante von SOAP wird verwendet, um das Dokument-basierte Web-Service-Muster zu implementieren.


6
2017-10-27 17:27



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

Beachten Sie, dass Document-Web-Services auch in Literal und Wrapared abgegrenzt werden und dass sie unterschiedlich sind. Einer der Hauptunterschiede besteht darin, dass letzterer BP 1.1-konform ist und der erste 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. Dies ist, denke ich, ein wesentlicher Unterschied, wenn es darum geht, den Namen der Operation, für den die Anfrage bestimmt ist, einfach herauszufinden.

In Bezug auf RPC-Literal im Vergleich zu Dokument-Wrapped kann die Dokument-Wrapped-Anfrage einfach mit dem Schema in der WSDL überprüft / validiert werden - ein großer Vorteil.

Ich würde vorschlagen, die Verwendung von "Document Wrapped" als Webservice-Typ aufgrund seiner Vorteile zu wählen.

SOAP in HTTP ist das SOAP-Protokoll, das an HTTP als Träger gebunden ist. SOAP könnte 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 marshalieren.

Wenn Sie XML über HTTP verwenden (und Sie können), wird es einfach als XML-Payload für HTTP-Anforderungen / -Antworten verstanden. Sie müssten das Framework für Marshal / Unmarshal, Fehlerbehandlung und so weiter bereitstellen.

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


3
2017-12-22 08:38