Neste cenário, o broker chama uma implementação de serviço da Web
existente. O WSDL para o serviço da Web já existe e é importado para criar um conjunto de mensagens.
Um fluxo de mensagens baseado nesse conjunto de mensagens envia uma solicitação de serviço da web
e recebe a resposta, por exemplo, usando um nó SOAPRequest.
Chave para os símbolos:
Utilizações Possíveis
- Você deseja chamar um serviço da Web para realizar algum processamento como parte de seu fluxo de mensagens.
- Você possui um serviço da Web existente e deseja fornecer uma interface
diferente para ele. Esta pode ser uma interface de serviços da Web alternativa ou uma interface do WebSphere MQ.
- Você possui um serviço da Web existente e deseja alterar sua implementação
de alguma forma sem alterar sua interface; ou seja, o intermediário age como um
mediador para o serviço da Web. Por exemplo, um fluxo de mensagens
pode ser utilizado para ativar a auditoria ou para propagar de forma transparente
a resposta do serviço da Web para outro aplicativo.
Etapas de Design
- Importe o WSDL para criar um conjunto de mensagens contendo definições para as mensagens SOAP
descritas pelo WSDL.
- Crie um fluxo de mensagens para chamar o serviço da Web. Se o domínio SOAP
for usado, o fluxo de mensagens usará um nó SOAPRequest, um nó SOAPAsyncRequest ou um nó SOAPAsyncResponse. Os nós são configurados usando o WSDL importado na Etapa 1. Se necessário, você pode criar um fluxo modelo a
partir do início, soltando o WSDL em uma tela do editor de fluxo de mensagens em branco. Se você usar o domínio SOAP,
deverá criar o fluxo de mensagens usando os nós de transporte e um domínio XML
ou MIME. Por exemplo, se a ligação de WSDL especificar o transporte HTTP,
e a mensagem de pedido for SOAP, você poderá usar um nó HTTPRequest com o
domínio XMLNSC. É possível, então, configurar o nó manualmente com as informações do terminal para o serviço da Web.
- Construa um arquivo archive do intermediário para implementação. O arquivo bar
contém seu fluxo de mensagens e o conjunto de mensagens que contém
o WSDL importado. O domínio SOAP sempre requer que a WSDL seja
implementada, porque as mensagens são verificadas com relação a ela no tempo de execução; além disso
as informações de WSDL são incluídas na árvore lógica. O conjunto de mensagens
inclui definições de Esquema XML que podem ser usados para validação de mensagem
nos domínios SOAP, XMLNSC ou MRM.
No Tempo de Execução
Seu fluxo de mensagens cria um pedido de serviço da Web
formatado corretamente, chama o serviço da Web e analisa a resposta
do serviço da Web. Se você usar o domínio SOAP, seu fluxo de mensagens
usará o modelo de árvore lógica SOAP. Se você não usar o domínio SOAP,
seu fluxo de mensagens usará a árvore lógica para seu domínio
selecionado; por exemplo, você usa o domínio MIME se suas mensagens
de serviço da Web usarem SOAP com Anexos.
Exemplo 1
- Intermediário do Serviço da Web
- Neste exemplo, um aplicativo cliente utiliza um serviço da Web chamado Account que é disponibilizado por outra organização. O cliente é amplamente distribuído em sua empresa. O cliente utiliza uma operação chamada getBalance, mas o serviço Account está sendo modificado para alterar a definição da operação getBalance. É possível construir os fluxos de mensagens para fornecer uma interface para o serviço Account. em vez de modificar o cliente. Os fluxos de mensagens podem chamar o serviço Account para fazer o trabalho e o novo serviço da Web delega para o serviço da Web original.
O cliente agora pode continuar usando o serviço Account, usando os novos fluxos de mensagens.
Nos exemplos de padrões de fluxo de mensagens típicos
mostrados aqui, o nó de pedido intermediário chama o serviço Account:
- Usando os nós SOAPInput, SOAPRequest e SOAPReply:
- Usando os nós SOAPInput, SOAPAsyncRequest, SOAPAsyncResponse e SOAPReply:
- Usando os nós HTTPInput, HTTPRequest e HTTPReply:
Nos fluxos de mensagens no exemplo,
Compute1 modifica a mensagem getBalance original conforme requerido pelo
serviço Account modificado, enquanto Compute2 restaura a
mensagem de resposta para o formato original. Se você tiver importado ou gerado
WSDL, terá um modelo de mensagem para a operação getBalance. Se você tiver
um modelo de mensagem definido para a operação getBalance, poderá utilizar os nós Mapeamento
em vez dos nós Compute.
Detalhes de HTTP
se você utilizar os nós de transporte HTTP, conforme mostrado no exemplo, é possível configurar o nó HTTPRequest para gerar cabeçalhos HTTP dos cabeçalhos recebidos pelo nó HTTPInput. Esta configuração
permite que cookies e outros cabeçalhos específicos do aplicativo sejam transmitidos
através do fluxo de mensagens. O nó HTTPReply pode ser utilizado para extrair cabeçalhos da resposta de serviço da Web, para retornar ao cliente de origem. Para criar esta configuração, selecione Gerar
cabeçalhos HTTP padrão a partir de em ambos os nós, HTTPRequest e HTTPReply. Geralmente,
não é necessário que a mensagem de pedido original gere a resposta
ao cliente e você pode selecionar Substituir mensagem de entrada por
resposta de serviço da Web no nó HTTPRequest. Se você
desejar preservar dados do pedido de entrada, poderá armazenar isto
no LocalEnvironment em Compute1 e recuperá-lo em Compute2 para
inclusão na resposta.
Exemplo 2
- Utilizando um Serviço da Web
- Neste exemplo, um fluxo de mensagens do WebSphere MQ
implementa um processo para o departamento de Recursos Humanos de sua
empresa. Como parte desse processamento, o fluxo de mensagens chama um serviço da Web para recuperar números de IDs de funcionários. Os números de IDs de funcionários são mantidos no diretório de funcionários da empresa que é acessado através de um serviço da Web.
Nos exemplos de padrões de fluxo de mensagens típicos mostrados
aqui, o nó de pedido broker recupera o ID do funcionário:
- Usando os nós MQInput, SOAPRequest e MQOutput:
- Usando os nós MQInput, SOAPAsyncRequest, SOAPAsyncResponse e MQOutput:
- Usando os nós MQInput, HTTPRequest e MQOutput:
Nos fluxos de mensagens do exemplo, Compute1 prepara a mensagem de pedido de serviço da Web e Compute2 processa a resposta.
Por exemplo, incorporando o ID do funcionário em outra mensagem.
Se você tiver um modelo de mensagem definido, poderá
utilizar nós Mapeamento em vez de nós Compute nestes exemplos.
Detalhes de HTTP
Se você utilizar os nós de transporte HTTP, conforme mostrado o exemplo, você geralmente desmarca Substituir Mensagem de Entrada por Resposta de Serviço da Web nas propriedades do nó
HTTPRequest.
A resposta do servidor de diretório corporativo é colocada em um local temporário na árvore de mensagens. O local temporário é especificado em Local da Mensagem de Resposta na propriedade da árvore no mesmo nó. Em Compute2, é possível codificar ESQL para recuperar o resultado e atualizar a mensagem final.
Utilizar o domínio SOAP para esses cenários é preferencial.
Para obter informações adicionais sobre a escolha de um domínio para serviços da Web, consulte WebSphere Message Broker e Serviços da Web.