web services - paso - ¿Cuál es la diferencia entre el estilo de documento y la comunicación de estilo RPC?
jax-ws download (5)
¿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 forma, al usar JAX-WS actualmente hago una anotación en el servicio con @Webservice , 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.
¿Puede algún organismo 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 de SOAP de la manera 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: literales y codificados
Cuando se usa 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 utilizando 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 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
Le recomendaría que lea 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, 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?
¡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.
- La desventaja básica del uso del estilo RPC es que no es compatible con tipos de datos más ricos y que el uso de estilo de documento es que trae cierta complejidad en forma de XSD para definir los tipos de datos más ricos.
- La elección de usar uno de estos depende de los 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 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, 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.
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
El escenario principal donde JAX-WS RPC y el estilo de documento se utilizan de la siguiente manera:
El patrón Llamada a procedimiento remoto (RPC) se usa 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 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.
El 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 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 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.
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, lo que hace que se acople débilmente. 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 entender
- Desventaja :
- no podemos validar los mensajes SOAP.
- estrechamente acoplado
RPC: no hay tipos en WSDL
Documento: sección de tipos estaría disponible en WSDL
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: SOAP Binding: Diferencia entre Document y RPC Style Web Services