¿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.