Pregunta ¿Cuál es la diferencia entre el estilo de documento y la comunicación de estilo RPC?


¿Alguien puede explicarme las diferencias entre los servicios web de estilo Document y RPC? Además de JAX-RPC, la próxima versión es JAX-WS, que admite estilos de documento y RPC. También entiendo que los servicios web de estilo de documento están destinados a la comunicación asincrónica, donde un cliente no bloquearía hasta que se reciba la respuesta.

De cualquier manera, usando JAX-WS actualmente anoto el servicio con @Servicio web, genero el WSDL y de ese WSDL genero los artefactos del lado del cliente.

Una vez que se reciben los artefactos, en ambos estilos, invoco el método en el puerto. Ahora, esto no difiere en estilo RPC y estilo de documento. Entonces, ¿cuál es la diferencia y dónde es visible esa diferencia?

Del mismo modo, ¿de qué manera difiere SOAP a través de HTTP de XML a través de HTTP? Después de todo, SOAP también es un documento XML con espacio de nombres SOAP.


76
2018-01-30 10:31


origen


Respuestas:


¿Puede algún cuerpo explicarme las diferencias entre un estilo de Documento y   Servicios web de estilo RPC?

Hay dos modelos de estilo de comunicación que se utilizan para traducir un enlace WSDL a un cuerpo de mensaje SOAP. Son:   Documento y RPC

los ventaja de usar un modelo de estilo de documento es que puedes estructurar el cuerpo SOAP de la forma que quieras, siempre y cuando el contenido del cuerpo del mensaje SOAP sea cualquier instancia XML arbitraria. El estilo de documento también se conoce como Estilo orientado al mensaje.

Sin embargo, con un Modelo de estilo RPC, la estructura del cuerpo de la solicitud SOAP debe contener tanto el nombre de la operación como el conjunto de parámetros del método. El modelo de estilo RPC asume una estructura específica para el Instancia XML contenido en el cuerpo del mensaje.

Además, hay dos modelos de uso de codificación que se utilizan para traducir un enlace WSDL a un mensaje SOAP. Son: literal y codificado

Cuando se usa un modelo de uso literal, el contenido del cuerpo debe ajustarse a un definido por el usuario Estructura de esquema XML (XSD). La ventaja es doble. Por un lado, puede validar el cuerpo del mensaje con el esquema XML definido por el usuario; además, también puede transformar el mensaje utilizando un lenguaje de transformación como XSLT.

Con un (SOAP) modelo de uso codificado, el mensaje tiene que usar tipos de datos XSD, pero la estructura del mensaje no necesita ajustarse a ningún esquema XML definido por el usuario. Esto dificulta la validación del cuerpo del mensaje o el uso de transformaciones basadas en XSLT en el cuerpo del mensaje.

La combinación de los diferentes modelos de estilo y uso nos da cuatro formas diferentes de traducir un enlace WSDL a un mensaje SOAP.

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

Yo recomendaría que lean este artículo titulado ¿Qué estilo de WSDL debería usar? por Russell Butek que tiene una agradable discusión sobre los diferentes estilos y modelos de uso para traducir un enlace WSDL a un mensaje SOAP, y sus fortalezas y debilidades relativas.

Una vez que se reciben los artefactos, en ambos estilos de comunicación,   invocar el método en el puerto. Ahora, esto no difiere en el estilo RPC   y estilo del documento. Entonces, ¿cuál es la diferencia y dónde es eso?   diferencia visible?

¡El lugar donde puedes encontrar la diferencia es la "RESPUESTA"!

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

El mensaje SOAP para la segunda operación tendrá salida vacía y se verá así:

Respuesta de estilo RPC:

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

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

Si ejecutamos el cliente para el SEI anterior, la salida es:

123 [123, 456]

Este resultado muestra que los elementos de ArrayList se intercambian entre el servicio web y el cliente. Este cambio solo se ha realizado cambiando el atributo de estilo de la anotación SOAPBinding. El mensaje SOAP para el segundo método con un tipo de datos más completo se muestra a continuación para referencia:

Respuesta de estilo del 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>

Conclusión

  • Como habrá notado en los dos mensajes de respuesta SOAP, es posible validar el mensaje de respuesta SOAP en el caso de estilo DOCUMENTO pero no en los servicios web de estilo RPC.
  • Lo básico desventaja de usar el estilo RPC es que no lo hace admite tipos de datos más ricos y el uso de estilo de documento es que trae cierta complejidad en forma de XSD para definir los más ricos tipos de datos.
  • La elección de usar uno de estos depende de la requisitos de operación / método y los clientes esperados.

Del mismo modo, ¿de qué manera SOAP a través de HTTP difiere de XML a través de HTTP? Después   todo SOAP también es un documento XML con espacio de nombres SOAP. Entonces, ¿qué es el   diferencia aquí?

¿Por qué necesitamos un estándar como SOAP? Al intercambiar documentos XML a través de HTTP, dos programas pueden intercambiar información rica y estructurada sin la introducción de un estándar adicional como SOAP para describir explícitamente un formato de sobre de mensaje y una forma de codificar contenido estructurado.

SOAP proporciona un estándar para que los desarrolladores no tengan que inventar un formato de mensaje XML personalizado para cada servicio que quieran poner a disposición. Dada la firma del método de servicio que se invocará, la especificación SOAP prescribe un formato de mensaje XML inequívoco. Cualquier desarrollador familiarizado con la especificación SOAP, trabajando en cualquier lenguaje de programación, puede formular una solicitud JAPE XML correcta para un servicio en particular y comprender la respuesta del servicio obteniendo los siguientes detalles del servicio.

  • Nombre del Servicio
  • Nombres de métodos implementados por el servicio
  • Firma del método de cada método
  • Dirección de la implementación del servicio (expresada como URI)

El uso de SOAP optimiza el proceso para exponer un componente de software existente como un servicio web, ya que la firma del método del servicio identifica la estructura del documento XML utilizada tanto para la solicitud como para la respuesta.


81
2018-02-04 13:23



Un servicio web de estilo RPC utiliza los nombres del método y sus parámetros para generar estructuras XML que representan la pila de llamadas de un método. El estilo del documento indica que el cuerpo de SOAP contiene un documento XML que se puede validar contra un documento de esquema XML predefinido.

Un buen punto de partida: Enlace SOAP: diferencia entre el documento y los servicios web de estilo RPC


21
2018-05-20 09:07



En la definición WSDL, los enlaces contienen operaciones, aquí viene el estilo para cada operación.

Documento: En el archivo WSDL, especifica los detalles de los tipos que tienen en línea O importa el documento XSD, que describe la estructura (es decir, el esquema) de los tipos de datos complejos que intercambian esos métodos de servicio que se acopla de forma flexible. El estilo del documento es predeterminado.

  • Ventaja:
    • Usando este estilo de documento, podemos validar los mensajes SOAP contra el esquema predefinido. Admite tipos de datos xml y patrones.
    • débilmente acoplado.
  • Desventaja: Es un poco difícil de entender.

En el elemento de tipos WSDL se ve de la siguiente manera:

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

El esquema está importando de referencia externa.

RPC : En el archivo WSDL, no crea el esquema de tipos, dentro de los elementos del mensaje define los atributos de nombre y tipo, lo que los hace estrechamente relacionados.

<types/>  
<message name="getHelloWorldAsString">  
<part name="arg0" type="xsd:string"/>  
</message>  
<message name="getHelloWorldAsStringResponse">  
<part name="return" type="xsd:string"/>  
</message>  
  • Ventaja: Fácil de comprender.
  • Desventaja:
    • no podemos validar los mensajes SOAP.
    • estrechamente acoplado

RPC: Sin tipos en WSDL
Documento: La sección de tipos estaría disponible en WSDL


14
2018-02-09 10:23



El escenario principal donde JAX-WS RPC y Documento estilo se utilizan de la siguiente manera:

  • los Llamada a procedimiento remoto (RPC) El patrón se usa cuando el consumidor ve el servicio web como una única aplicación o componente lógico con datos encapsulados. Los mensajes de solicitud y respuesta se asignan directamente a los parámetros de entrada y salida de la llamada de procedimiento.

    Ejemplos de este tipo el patrón RPC podría incluir un servicio de pago o un servicio de cotización de acciones.

  • los patrón basado en documentos se usa en situaciones en las que el consumidor ve el servicio web como un proceso comercial más extenso en el que el documento de solicitud representa una unidad completa de información. Este tipo de servicio web puede involucrar interacción humana para ejemplo como con un documento de solicitud de solicitud de crédito con un documento de respuesta que contiene las ofertas de las instituciones de crédito. Debido a que los procesos comerciales más largos pueden no ser capaces de devolver el documento solicitado inmediatamente, el patrón basado en documentos se encuentra más comúnmente en arquitecturas de comunicación asíncronas. La variación Documento / literal de SOAP se utiliza para implementar el patrón de servicio web basado en documentos.


6
2017-10-27 17:27



Creo que lo que está preguntando es la diferencia entre RPC Literal, Document Literal y Document Wrapped SOAP web services.

Tenga en cuenta que los servicios web de documentos también están delineados en literal y se envuelven, y son diferentes: una de las diferencias principales es que este último cumple con BP 1.1 y el primero no.

Además, en Document Literal, la operación a invocar no se especifica en términos de su nombre, mientras que en Wrapped, sí lo está. Esto, creo, es una diferencia significativa en términos de averiguar fácilmente el nombre de la operación para la que se solicita.

En términos de RPC literal versus Documento envuelto, la solicitud Envoltura de documento puede ser fácilmente verificada / validada contra el esquema en el WSDL, una gran ventaja.

Sugiero usar Document Wrapped como el tipo de servicio web de elección debido a sus ventajas.

SOAP en HTTP es el protocolo SOAP vinculado a HTTP como el operador. SOAP también podría ser SMTP o XXX. SOAP proporciona una forma de interacción entre entidades (cliente y servidores, por ejemplo) y ambas entidades pueden ordenar argumentos de operación / valores de retorno según la semántica del protocolo.

Si usaba XML a través de HTTP (y puede hacerlo), simplemente se entiende que es XML payload en solicitud / respuesta HTTP. Tendría que proporcionar el marco para el marshal / unmarshal, el manejo de errores y demás.

Un tutorial detallado con ejemplos de WSDL y código con énfasis en Java: SOAP y JAX-WS, RPC versus Document Web Services


3
2017-12-22 08:38