Los nodos
SOAPInput,
SOAPRequest
y
SOAPAsyncRequest
tienen dos modalidades de funcionamiento: la
modalidad WSDL y la modalidad de pasarela.
Si el nodo está configurado para funcionar en
modalidad WSDL, que es el valor predeterminado,
esto indica que las operaciones del servicio web
realizadas por el nodo se especifican mediante un
WSDL que configura el nodo. En la modalidad de
pasarela, los nodos SOAP de un flujo de mensajes
manejan mensajes de solicitud SOAP genéricos en
los siguientes escenarios.
- Caso de ejemplo de proveedor
- En un escenario de proveedor,
WebSphere Message Broker recibe
solicitudes SOAP/HTTP o SOAP/JMS genéricas
utilizando un nodo
SOAPInput,
y envía una respuesta al cliente de origen
utilizando un nodo SOAPReply. Un único nodo SOAPInput puede recibir cualquier mensaje de solicitud SOAP y no está configurado con un WSDL.
- Caso de ejemplo de consumidor
- En un escenario consumidor,
WebSphere Message Broker puede
direccionar una solicitud SOAP a cualquier
proveedor de servicios web externo utilizando el
nodo
SOAPRequest
o un par de nodos
SOAPAsyncRequest y SOAPAsyncResponse. La información de punto final se puede
especificar en el entorno local, que se utiliza
dinámicamente en tiempo de ejecución para enviar
el mensaje de solicitud de salida.
- Caso de ejemplo de fachada
- En un caso de ejemplo de fachada,
WebSphere Message Broker puede
recibir solicitudes SOAP de varios clientes
distintos y direccionarlas a cualquiera de los
diversos proveedores de servicios web de fondo o
a los sistemas existentes. La información de
punto final del proveedor de servicio web de
fondo se puede especificar dinámicamente en
tiempo de ejecución estableciendo valores en el
entorno local.
Los nodos SOAP actúan y se configuran de forma
diferente en las dos modalidades de funcionamiento
diferentes.
- Si configura un nodo en modalidad de pasarela, algunas propiedades de nodo se inhabilitan porque no son aplicables en la modalidad de pasarela.
- Deben configurarse las propiedades de
transporte. Las propiedades específicas del
transporte son obligatorias en función de la
propiedad
Transporte;
por ejemplo, las propiedades de transporte JMS
son obligatorias si la opción
Transporte
seleccionada es
JMS.
- Un nodo SOAPInput sólo se puede configurar para recibir mensajes de un único transporte especificado; por ejemplo, HTTP. Utilice nodos de entrada separados para enviar o recibir mensajes con transportes diferentes.
- Un nodo SOAPRequest sólo se puede configurar para enviar mensajes de un único transporte especificado; por ejemplo, JMS. Sin embargo, puede cambiar el transporte de cualquier mensaje utilizando el entorno local.
- Un nodo
SOAPAsyncRequest
sólo se puede configurar para enviar y recibir
mensajes a través de un único transporte, por
ejemplo, JMS, y este transporte siempre se
utiliza para el nodo emparejado
SOAPAsyncResponse
para recibir el mensaje de respuesta. Sin
embargo, puede cambiar el transporte de la
solicitud de salida para cualquier mensaje
utilizando el entorno local.
Por ejemplo, si un nodo SOAPAsyncRequest está configurado para utilizar el transporte JMS, su nodo SOAPAsyncResponse emparejado siempre prevé recibir respuestas a través de JMS y esto no es modificable.
En tiempo de ejecución, el nodo
SOAPAsyncRequest
también presupone que JMS es el transporte
predeterminado. No obstante, puede darle instrucciones para que
envíe la solicitud a través de HTTP utilizando el
entorno local.
Esta solicitud incluye la dirección WSA:ReplyTo JMS para el nodo SOAPAsyncResponse.
- Si un nodo SOAPInput recibe una solicitud SOAP unidireccional, el nodo intenta detectar que es un mensaje unidireccional. No obstante, el nodo no puede detectar todos los
casos y por lo tanto, a veces es necesario
indicar al nodo
SOAPReply
que se trata de un mensaje unidireccional,
utilizando el entorno local. Por ejemplo:
SET OutputLocalEnvironment.Destination.SOAP.Reply.Gateway.OneWay = True;
Para obtener más información, consulte
Mensajes unidireccionales en modalidad de pasarela.
- Si utiliza el nodo
SOAPAsyncRequest
en modalidad de pasarela, debe establecer la
propiedad WS_Addressing
Action
en el entorno local del flujo de mensajes antes
que el nodo
SOAPAsyncRequest. Establezca esta propiedad utilizando OutputLocalEnvironment.Destination.SOAP.Request.WSA.Action.
- Si utiliza el nodo
SOAPRequest
en modalidad de pasarela y el proveedor de
servicios remotos espera una SOAPaction,
establezca SOAPaction en el flujo. En modalidad
de pasarela la SOAPaction desde un WDSL no está
disponible para el nodo. Por ejemplo, para
establecer SOAPAction utilizando ESQL:
SET OutputRoot.HTTPRequestHeader.SOAPAction = 'mySoapAction';
De forma predeterminada, el nodo
SOAPRequest
envía una SOAPAction vacía de "".
- Si utiliza el nodo
SOAPRequest
en modalidad de pasarela y utiliza WS-Addressing,
debe establecer la propiedad
Acción
de WS-Addressing en el entorno local del flujo de
mensajes antes que el nodo SOAPRequest. Establezca esta propiedad utilizando OutputLocalEnvironment.Destination.SOAP.Request.WSA.Action.
- En la modalidad de pasarela, puede añadir cabeceras de entrada "debe comprender" al nodo SOAPInput o a los nodos SOAPRequest y SOAPAsyncRequest especificando los detalles en la propiedad del nodo. No obstante, si va a añadir servicios dinámicamente, donde las cabeceras "debe comprender" no se pueden conocer de forma anticipada, puede añadir estas cabeceras con un comodín (*)
para el nombre, el espacio de nombres, la operación o cualquier combinación de los tres. Esto suprime la necesidad de volver a desplegar el flujo de mensajes cuando se añaden nuevos servicios. No obstante, tenga en cuenta que si añade un comodín para el nombre, el espacio de nombres y también la operación, esto significa que todas las cabeceras con un distintivo "debe comprender" están permitidas en el flujo.
- Si utiliza el nodo
SOAPReply
como parte de un flujo de mensajes de fachada,
con el nodo
SOAPInput
establecido en la modalidad de pasarela y el nodo
SOAPRequest
actuando en modalidad WSDL, inhabilite la
validación del nodo
SOAPReply
o añada un Conjunto de mensajes explícito en la
carpeta Propiedades como se documenta
anteriormente. Si no inhabilita la
validación o referencia un Conjunto de mensajes
en la carpeta Propiedades, ocurren errores de
análisis cuando el mensaje se serializa.
- En modalidad de pasarela, los nodos SOAP
envían el mensaje SOAP 1.1 de forma
predeterminada, aunque también aceptan los
mensajes SOAP 1.2 de entrada. Para enviar un mensaje SOAP 1.2 de salida, establezca el campo SOAP.Context para indicar que SOAP 1.2 es necesario. Por
ejemplo, para establecer este campo utilizando ESQL:
SET OutputRoot.SOAP.Context.SOAP_Version = '1.2';
El mensaje de salida utiliza un sobre SOAP SOAP 1.2. También puede establecer el prefijo del espacio de nombres utilizado por el sobre SOAP. Por ejemplo, utilizando ESQL:DECLARE soapenc NAMESPACE 'http://www.w3.org/2003/05/soap-envelope';
SET OutputRoot.SOAP.Context.Namespace.(SOAP.NamespaceDecl)xmlns:soap12 = soapenc;
SET OutputRoot.SOAP.Context.SOAP_Version = '1.2';
En este ejemplo, soap12 es el prefijo utilizado en el mensaje de salida.