¿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 siguiente versión es JAX-WS, que admite tanto los estilos Document como 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 se bloquearía hasta que se reciba la respuesta.

De cualquier manera, usando JAX-WS, actualmente anoto el servicio con @Webservice , genero el WSDL y, a partir 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 bien, esto no difiere en el estilo RPC y el estilo del documento. Entonces, ¿cuál es la diferencia y dónde es visible esa diferencia?

De manera similar, ¿en qué se diferencia SOAP sobre HTTP de XML sobre HTTP? Después de todo, SOAP también es un documento XML con espacio de nombres SOAP.

¿Puede alguien explicarme las diferencias entre un estilo de documento y los 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. Ellos son: Documento y RPC

La ventaja de utilizar un modelo de estilo de documento es que puede estructurar el cuerpo SOAP de la forma que desee, siempre que el contenido del cuerpo del mensaje SOAP sea cualquier instancia XML arbitraria. El estilo de documento también se conoce como estilo orientado a mensajes .

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 la instancia XML contenida 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 utiliza un modelo de uso literal , el contenido del cuerpo debe ajustarse a una estructura de esquema XML (XSD) definida por el usuario . 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 usando un lenguaje de transformación como XSLT.

Con un modelo de uso codificado (SOAP) , 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 diferentes estilos y modelos de uso nos brinda cuatro formas diferentes de traducir un enlace WSDL a un mensaje SOAP.

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

Le recomendaría que lea este artículo titulado ¿Qué estilo de WSDL debo usar? por Russell Butek, que tiene una buena 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, invoco el método en el puerto. Ahora bien, esto no difiere en el estilo RPC y el estilo del documento. Entonces, ¿cuál es la diferencia y dónde es visible esa diferencia?

¡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á una 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, el resultado es:

123 [123, 456]

Esta salida muestra que los elementos ArrayList se intercambian entre el servicio web y el cliente. Este cambio se ha realizado solo 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 rico se muestra a continuación como referencia:

Respuesta de estilo de 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 del estilo DOCUMENT, pero no en los servicios web de estilo RPC.
• La desventaja básica de usar el estilo RPC es que no admite tipos de datos más ricos y la de usar el estilo Documento es que aporta cierta complejidad en forma de XSD para definir los tipos de datos más ricos.
• La elección de utilizar uno de estos depende de los requisitos de operación / método y los clientes esperados.

De manera similar, ¿en qué se diferencia SOAP sobre HTTP de XML sobre HTTP? Después de todo, SOAP también es un documento XML con espacio de nombres SOAP. Entonces, ¿cuál es la 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, que trabaje en cualquier lenguaje de programación, puede formular una solicitud XML SOAP correcta para un servicio en particular y comprender la respuesta del servicio al obtener 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 agiliza 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.

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 con un documento de esquema XML predefinido.

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

En la definición de 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 documentos XSD en línea o importados, que describen la estructura (es decir, el esquema) de los tipos de datos complejos que se intercambian mediante esos métodos de servicio, lo que hace que estén débilmente acoplados. El estilo del documento es el predeterminado.

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

En los tipos de WSDL, el elemento tiene el siguiente aspecto:

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

El esquema se está importando desde una referencia externa.

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

<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 entender.
• Desventaja :
  • no podemos validar los mensajes SOAP.
  • estrechamente acoplado

RPC: No hay tipos en WSDL
Documento: la sección Tipos estaría disponible en WSDL

El escenario principal en el que JAX-WS RPC y el estilo de documento se utilizan de la siguiente manera:

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

  Ejemplos de este tipo de patrón de RPC pueden incluir un servicio de pago o un servicio de cotización de acciones.

• El patrón basado en documentos se utiliza en situaciones en las que el consumidor ve el servicio web como un proceso comercial de ejecución más prolongada donde el documento de solicitud representa una unidad completa de información. Este tipo de servicio web puede implicar interacción humana, por ejemplo, como con un documento de solicitud de solicitud de crédito con un documento de respuesta que contiene ofertas de instituciones crediticias. Debido a que es posible que los procesos comerciales de ejecución más larga no puedan devolver el documento solicitado de inmediato, el patrón basado en documentos se encuentra más comúnmente en arquitecturas de comunicación asincrónica. La variación Documento / literal de SOAP se utiliza para implementar el patrón de servicio web basado en documentos.

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

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

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

En términos de literal de RPC frente a documento envuelto, la solicitud de documento envuelto se puede examinar / validar fácilmente contra el esquema en el WSDL, una gran ventaja.

Sugeriría 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 operador. SOAP también podría estar sobre SMTP o XXX. SOAP proporciona una forma de interacción entre entidades (cliente y servidores, por ejemplo) y ambas entidades pueden ordenar los argumentos de operación / valores de retorno según la semántica del protocolo.

Si estaba utilizando XML sobre HTTP (y puede hacerlo), simplemente se entiende que es una carga útil XML en una solicitud / respuesta HTTP. Debería proporcionar el marco para ordenar / desmarcar, manejo de errores, etc.

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

Documento
Los mensajes de estilo de documento se pueden validar con un esquema predefinido. En el estilo de documento, el mensaje SOAP se envía como un solo documento. Ejemplo de esquema:

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

Ejemplo de mensaje de cuerpo de jabón de estilo de documento

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

El mensaje de estilo de documento está débilmente acoplado.

RPC Los mensajes de estilo RPC utilizan el nombre del método y los parámetros para generar la estructura XML. los mensajes son difíciles de validar contra el esquema. En el estilo RPC, el mensaje SOAP se envía tantos elementos.

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

Aquí, cada parámetro se especifica de forma discreta, el mensaje de estilo RPC está estrechamente acoplado, es típicamente estático y requiere cambios en el cliente cuando cambia la firma del método El estilo rpc se limita a tipos XSD muy simples como String e Integer, y el WSDL resultante no lo hará incluso tener una sección de tipos para definir y restringir los parámetros

Literal Por estilo predeterminado. Los datos se serializan de acuerdo con un esquema, el tipo de datos no se especifica en los mensajes, pero se utiliza una referencia al esquema (espacio de nombres) para crear mensajes SOAP.

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

Tipo de datos codificado especificado en cada parámetro

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

Sin esquema