Os nós SOAPInput, SOAPRequest e SOAPAsyncRequest possuem
dois modos de operação: modo WSDL e modo de Gateway.
Se o nó for configurado para estar no modo WSDL, que é o padrão,
as operações de serviço da Web executadas pelo nó serão especificadas por
um WSDL que configura o nó. No modo de Gateway, os nós SOAP de um
fluxo de mensagens tratam de mensagens de solicitação genérica de SOAP nos cenários
a seguir.
- Cenário de provedor
- Em um cenário de provedor, o WebSphere Message Broker recebe
solicitações genéricas de SOAP/HTTP ou SOAP/JMS usando um nó SOAPInput e envia uma
resposta para o cliente de origem usando um nó SOAPReply. Um único nó SOAPInput pode receber qualquer mensagem de solicitação SOAP e não é configurada com um WSDL.
- Cenário do consumidor
- Em um cenário de consumidor, o WebSphere Message Broker pode
rotear uma solicitação de SOAP para qualquer provedor externo de serviço da Web usando
o nó SOAPRequest ou
um par de nós SOAPAsyncRequest e SOAPAsyncResponse. É possível
especificar informações de terminal no ambiente local, que serão usadas
dinamicamente no tempo de execução para enviar a mensagem de solicitação de saída.
- Cenário da fachada
- Em um cenário de fachada, o WebSphere Message Broker pode
receber solicitações de SOAP de vários clientes diferentes, e roteá-los
para qualquer um dos diversos provedores de serviços da Web de back end, ou para sistemas
existentes. É possível especificar informações de terminal para provedores de serviços
da Web de back-end dinamicamente no tempo de execução configurando valores no
ambiente local.
Os nós SOAP agem e são configurados de forma diferente nos dois modos de
operação diferentes.
- Se você configurar um nó no modo de gateway, algumas propriedades do nó serão desativadas, porque não são aplicáveis no modo de gateway.
- As propriedades de transporte deve ser configuradas. As propriedades
específicas do transporte são obrigatórias, dependendo da propriedade Transporte; por exemplo,
as propriedades de transporte JMS serão obrigatórias se o transporte selecionado
for JMS.
- Um nó SOAPInput pode ser configurado somente para receber mensagens de um único transporte especificado, por exemplo, HTTP. Use nós de entrada separados para enviar ou receber mensagens com transportes diferentes.
- Um nó SOAPRequest pode ser configurado somente para enviar mensagens de um único transporte especificado, por exemplo, JMS. Entretanto, é possível alterar o transporte para qualquer mensagem usando o ambiente local.
- Um nó SOAPAsyncRequest
pode ser configurado somente para enviar e receber mensagens por meio de um único
transporte, por exemplo, JMS, e esse transporte é sempre usado para
o par de nós SOAPAsyncResponse
para receber a mensagem de resposta. No entanto, é possível alterar o transporte de
solicitação de saída de qualquer mensagem usando o ambiente local.
Por exemplo, se um nó SOAPAsyncRequest for configurado para usar o transporte JMS, seu nó SOAPAsyncResponse pareado sempre irá esperar receber respostas no JMS, e isso não pode ser alterado.
No tempo de execução, o nó SOAPAsyncRequest
também assume o JMS como o transporte padrão. No entanto, é possível orientá-lo,
como alternativa, para que envie a solicitação via HTTP usando o ambiente local.
Esta solicitação inclui o endereço WSA:ReplyTo JMS para o nó SOAPAsyncResponse.
- Se um nó SOAPInput receber uma solicitação SOAP unidirecional, o nó tentará detectar se é uma mensagem unidirecional. No entanto, o nó não pode detectar todos os casos e,
assim, é necessário, às vezes, informar o nó SOAPReply que se trata de uma
mensagem unidirecional, usando o ambiente local. Por exemplo:
SET OutputLocalEnvironment.Destination.SOAP.Reply.Gateway.OneWay = True;
Para obter informações adicionais, consulte Mensagens Unidirecionais no Modo de Gateway.
- Se você usar o nó SOAPAsyncRequest
no modo de Gateway, deverá configurar a propriedade Ação de WS-Addressing no ambiente local
no fluxo de mensagens antes do nó SOAPAsyncRequest. Configure esta propriedade usando OutputLocalEnvironment.Destination.SOAP.Request.WSA.Action.
- Se você usar o nó SOAPRequest
no modo de Gateway e o provedor de serviços remotos esperar uma SOAPAction,
configure a SOAPAction no fluxo. No modo de Gateway, a SOAPAction de
um WSDL não está disponível para o nó. Por exemplo, para configurar a SOAPAction
usando ESQL:
SET OutputRoot.HTTPRequestHeader.SOAPAction = 'mySoapAction';
Por padrão, o nó SOAPRequest
envia uma SOAPAction vazia de "".
- Se você usar o nó SOAPRequest
no modo de Gateway e estiver usando WS-Addressing, deverá configurar a propriedade Ação de WS-Addressing no ambiente local
no fluxo de mensagens antes do nó SOAPRequest. Configure esta propriedade usando OutputLocalEnvironment.Destination.SOAP.Request.WSA.Action.
- No modo de Gateway, é possível incluir cabeçalhos de entrada "deve entender" no nó
SOAPInput ou nos nós
SOAPRequest e
SOAPAsyncRequest especificando os detalhes na
propriedade do nó. Entretanto, se for incluir serviços dinamicamente, em que todos os cabeçalhos "deve entender" não possam ser conhecidos com antecedência, será possível incluir esses cabeçalhos com um curinga (*) para um nome, namespace, operação ou qualquer combinação dos três. Isso
elimina a necessidade de reimplementar o fluxo de mensagens quando novos serviços são
incluídos. Entretanto, considere que, se for incluído um curinga no nome, namespace e
também na operação, isso significará que todos os cabeçalhos com um sinalizador "deve
entender" serão permitidos no fluxo.
- Se você usar o nó SOAPReply
como parte de um fluxo de mensagens de fachada, com o nó SOAPInput configurado no modo de
Gateway e o nó SOAPRequest
agindo no modo WSDL, desative a validação no nó SOAPReply ou inclua um Conjunto de
Mensagens explícito na pasta Propriedades, conforme documentado acima. Se você
não desativar a validação ou fizer referência a um Conjunto de Mensagens na pasta
Propriedades, ocorrerão erros de análise quando a mensagem for serializada.
- No modo de Gateway, os nós SOAP enviam mensagens SOAP 1.1 por padrão,
embora também aceitem mensagens SOAP 1.2 de entrada. Para enviar uma mensagem de saída SOAP 1.2, configure o campo SOAP.Context para indicar que o SOAP 1.2 é requerido. Por exemplo, para configurar esse campo usando ESQL:
SET OutputRoot.SOAP.Context.SOAP_Version = '1.2';
A mensagem de saída, em seguida, usa um Envelope SOAP do SOAP 1.2. Também é possível configurar o prefixo de namespace usado pelo Envelope SOAP. Por exemplo,
usando 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';
Neste exemplo, soap12 é o prefixo usado na mensagem de saída.