Czy ktoś może mi wyjaśnić różnice między usługami sieciowymi w stylu dokumentów i RPC? Oprócz JAX-RPC, następną wersją jest JAX-WS, który obsługuje zarówno style dokumentów, jak i RPC. Rozumiem również, że usługi sieciowe w stylu dokumentu są przeznaczone do komunikacji asynchronicznej, w której klient nie blokowałby się do momentu otrzymania odpowiedzi.
Tak czy inaczej, za pomocą JAX-WS aktualnie adnotuję usługę za pomocą @Webservice , generuję WSDL iz tego WSDL generuję artefakty po stronie klienta.
Po odebraniu artefaktów w obu stylach wywołuję metodę na porcie. Teraz nie różni się to stylem RPC i stylem dokumentu. Więc jaka jest różnica i gdzie ta różnica jest widoczna?
Podobnie, w jaki sposób protokół SOAP przez HTTP różni się od XML przez HTTP? W końcu SOAP to także dokument XML z przestrzenią nazw SOAP.
Odpowiedzi:
Istnieją dwa modele stylów komunikacji, które są używane do tłumaczenia powiązania WSDL na treść komunikatu SOAP. Są to: Dokument i RPC
Zaletą przy użyciu modelu styl dokumentu jest to, że można zorganizować ciału mydło jakikolwiek sposób chcesz go tak długo, jak zawartość treści wiadomości SOAP jest każda dowolna instancja XML. Styl dokumentu jest również nazywany stylem zorientowanym na komunikaty .
Jednak w modelu stylu RPC struktura treści żądania SOAP musi zawierać zarówno nazwę operacji, jak i zestaw parametrów metody. Model stylu RPC zakłada określoną strukturę instancji XML zawartej w treści wiadomości.
Ponadto istnieją dwa modele użycia kodowania, które są używane do tłumaczenia powiązania WSDL na komunikat SOAP. Są: dosłowne i zakodowane
W przypadku korzystania z modelu użycia literału zawartość treści powinna być zgodna ze strukturą schematu XML (XSD) zdefiniowaną przez użytkownika . Zaleta jest podwójna. Po pierwsze, możesz zweryfikować treść wiadomości za pomocą schematu XML zdefiniowanego przez użytkownika, a ponadto możesz również przekształcić wiadomość przy użyciu języka transformacji, takiego jak XSLT.
W przypadku modelu użycia zakodowanego (SOAP) komunikat musi używać typów danych XSD, ale struktura komunikatu nie musi być zgodna z żadnym schematem XML zdefiniowanym przez użytkownika. Utrudnia to weryfikację treści wiadomości lub używanie przekształceń opartych na XSLT w treści wiadomości.
Połączenie różnych stylów i modeli użytkowania daje nam cztery różne sposoby tłumaczenia powiązania WSDL na wiadomość SOAP.
Document/literal Document/encoded RPC/literal RPC/encodedPolecam przeczytanie tego artykułu zatytułowanego Który styl WSDL powinienem użyć? autorstwa Russella Buteka, który ma fajną dyskusję na temat różnych stylów i używa modeli do tłumaczenia powiązania WSDL na wiadomość SOAP oraz ich względnych mocnych i słabych stron.
Miejscem, w którym można znaleźć różnicę, jest „ODPOWIEDŹ”!
Styl 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); }Komunikat SOAP dla drugiej operacji będzie miał puste wyjście i będzie wyglądał następująco:
Odpowiedź w stylu RPC:
<ns2:getStockPriceListResponse xmlns:ns2="http://sample.com/"> <return/> </ns2:getStockPriceListResponse> </S:Body> </S:Envelope>Styl dokumentu:
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); }Jeśli uruchomimy klienta dla powyższego SEI, wynik będzie:
123 [123, 456]
Te dane wyjściowe pokazują, że elementy ArrayList są wymieniane między usługą internetową a klientem. Ta zmiana została dokonana tylko przez zmianę atrybutu stylu adnotacji SOAPBinding. Komunikat SOAP dla drugiej metody z bogatszym typem danych jest pokazany poniżej w celach informacyjnych:
Odpowiedź dotycząca stylu dokumentu:
<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>Wniosek
Dlaczego potrzebujemy standardu takiego jak SOAP? Wymieniając dokumenty XML za pośrednictwem protokołu HTTP, dwa programy mogą wymieniać bogate, ustrukturyzowane informacje bez wprowadzania dodatkowego standardu, takiego jak SOAP, w celu jawnego opisania formatu koperty wiadomości i sposobu kodowania ustrukturyzowanej treści.
SOAP zapewnia standard, dzięki czemu programiści nie muszą wymyślać niestandardowego formatu wiadomości XML dla każdej usługi, którą chcą udostępnić. Biorąc pod uwagę sygnaturę wywoływanej metody usługi, specyfikacja SOAP określa jednoznaczny format komunikatu XML. Każdy programista zaznajomiony ze specyfikacją SOAP, pracujący w dowolnym języku programowania, może sformułować poprawne żądanie XML SOAP dla określonej usługi i zrozumieć odpowiedź usługi, uzyskując następujące szczegóły usługi.
Użycie protokołu SOAP usprawnia proces ujawniania istniejącego komponentu oprogramowania jako usługi sieci Web, ponieważ sygnatura metody usługi identyfikuje strukturę dokumentu XML używaną zarówno w przypadku żądania, jak i odpowiedzi.
źródło
Usługa internetowa w stylu RPC wykorzystuje nazwy metody i jej parametry do generowania struktur XML reprezentujących stos wywołań metody. Styl dokumentu wskazuje, że treść protokołu SOAP zawiera dokument XML, który można zweryfikować względem wstępnie zdefiniowanego dokumentu schematu XML.
Dobry punkt wyjścia: powiązanie SOAP: różnica między usługami sieci Web w stylu dokumentów i RPC
źródło
W definicji WSDL powiązania zawierają operacje, tutaj pojawia się styl dla każdej operacji.
Dokument: W pliku WSDL określa szczegóły typów, które mają wbudowany lub importuje dokument XSD, który opisuje strukturę (tj. Schemat) złożonych typów danych wymienianych przez te metody usługi, co powoduje luźne powiązanie. Styl dokumentu jest domyślny.
W typach WSDL element wygląda następująco:
<types> <xsd:schema> <xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/> </xsd:schema> </types>Schemat jest importowany z odnośnika zewnętrznego.
RPC : W pliku WSDL nie tworzy schematu typów, w elementach komunikatu definiuje atrybuty nazwy i typu, co sprawia, że są ściśle powiązane.
<types/> <message name="getHelloWorldAsString"> <part name="arg0" type="xsd:string"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="return" type="xsd:string"/> </message>RPC: brak typów w
dokumencie WSDL : sekcja Typy byłaby dostępna w WSDL
źródło
Główny scenariusz, w którym JAX-WS RPC i styl dokumentu są używane w następujący sposób:
Remote Procedure Call (RPC) wzór jest stosowany, gdy widzi konsument usługę internetową jako pojedynczy logiczny aplikacji lub komponentu z obudowanych danych. Komunikaty żądań i odpowiedzi są mapowane bezpośrednio na parametry wejściowe i wyjściowe wywołania procedury.
Przykładami tego typu wzorca RPC może być usługa płatnicza lub usługa notowań giełdowych.
Wzór dokumentu oparte jest stosowany w sytuacjach, w których konsument postrzega usługę internetową jako już uruchomiony proces biznesowy, w którym dokument wniosek stanowi kompletną całość informacji. Ten rodzaj usługi internetowej może obejmować interakcję człowieka, na przykład w przypadku wniosku o kredyt z dokumentem odpowiedzi zawierającym oferty instytucji pożyczkowych. Ponieważ dłużej działające procesy biznesowe mogą nie być w stanie natychmiast zwrócić żądanego dokumentu, wzorzec oparty na dokumencie jest częściej spotykany w architekturach komunikacji asynchronicznej. Odmiana dokumentu / literału protokołu SOAP służy do implementacji wzorca usługi sieci Web opartego na dokumencie.
źródło
Myślę, że pytasz o różnicę między usługami sieciowymi RPC Literal, Document Literal i Document Wrapped SOAP.
Należy zauważyć, że usługi sieciowe Document są podzielone na dosłowne i opakowane, a także różnią się - jedną z głównych różnic jest to, że ta ostatnia jest zgodna z BP 1.1, a ta pierwsza nie.
Ponadto w literale dokumentu operacja, która ma zostać wywołana, nie jest określona pod względem nazwy, podczas gdy w przypadku Wrapped jest. Myślę, że jest to znacząca różnica, jeśli chodzi o łatwe ustalenie nazwy operacji, której dotyczy żądanie.
Jeśli chodzi o literał RPC w porównaniu z opakowaniem w dokumencie, żądanie opakowanego dokumentu można łatwo zweryfikować / zweryfikować względem schematu w WSDL - jedna duża zaleta.
Sugerowałbym użycie Document Wrapped jako typu usługi internetowej z wyboru ze względu na jego zalety.
SOAP on HTTP to protokół SOAP powiązany z HTTP jako nośnikiem. SOAP może być również używany przez SMTP lub XXX. SOAP zapewnia sposób interakcji między jednostkami (na przykład klientem i serwerami) i obie jednostki mogą organizować argumenty operacji / zwracać wartości zgodnie z semantyką protokołu.
Jeśli korzystałeś z XML przez HTTP (i możesz), rozumie się po prostu jako ładunek XML na żądanie / odpowiedź HTTP. Będziesz musiał dostarczyć strukturę do organizowania / unmarshal, obsługi błędów i tak dalej.
Szczegółowy samouczek z przykładami WSDL i kodu z naciskiem na język Java: SOAP i JAX-WS, RPC kontra Document Web Services
źródło
Dokument
Komunikaty w stylu dokumentu można zweryfikować pod kątem predefiniowanego schematu. W stylu dokumentu wiadomość SOAP jest wysyłana jako pojedynczy dokument. Przykład schematu:
<types> <xsd:schema> <xsd:import namespace="http://example.com/" schemaLocation="http://localhost:8080/ws/hello?xsd=1"/> </xsd:schema> </types>Przykład wiadomości z mydłem w stylu dokumentu
<message name="getHelloWorldAsString"> <part name="parameters" element="tns:getHelloWorldAsString"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="parameters"> element="tns:getHelloWorldAsStringResponse"/> </message>Komunikat w stylu dokumentu jest luźno powiązany.
Komunikaty w stylu RPC RPC używają nazwy metody i parametrów do generowania struktury XML. komunikaty są trudne do zweryfikowania względem schematu. W stylu RPC wiadomość SOAP jest wysyłana jako wiele elementów.
<message name="getHelloWorldAsString"> <part name="arg0"> type="xsd:string"/> </message> <message name="getHelloWorldAsStringResponse"> <part name="return" > type="xsd:string"/> </message>Tutaj każdy parametr jest dyskretnie określony, komunikat w stylu RPC jest ściśle powiązany, jest zwykle statyczny, wymagający zmian po stronie klienta, gdy zmienia się sygnatura metody Styl rpc jest ograniczony do bardzo prostych typów XSD, takich jak String i Integer, a wynikowy WSDL nie będzie mają nawet sekcję typów do definiowania i ograniczania parametrów
Dosłowny Domyślny styl. Dane są serializowane zgodnie ze schematem, typ danych nie jest określony w komunikatach, ale odwołanie do schematu (przestrzeni nazw) jest używane do tworzenia wiadomości mydlanych.
<soap:body> <myMethod> <x>5</x> <y>5.0</y> </myMethod> </soap:body>Zakodowany typ danych określony w każdym parametrze
<soap:body> <myMethod> <x xsi:type="xsd:int">5</x> <y xsi:type="xsd:float">5.0</y> </myMethod> </soap:body>Bez schematu
źródło