Execute Serviços com Mais Facilidade Usando Gateway de Serviço

Introdução

Usando o WebSphere Integration Developer V6.2, é possível iniciar rapidamente a construir aplicativos usando modelos que representam as soluções de padrão. Um dos padrões que está disponível no WebSphere Integration Developer V6.2 é o Service Gateway, mostrado na Figura 1.

O seguinte corresponde aos números na Figura 1 e descreve as funções e benefícios de um gateway de serviço.

1. Forneça aos solicitantes de serviço um único ponto de acesso simplificado

   O acesso simplificado é obtido pelo fornecimento de um fluxo de mediação com uma interface genérica de gateway de serviço para mediar mensagens de diferentes solicitantes de serviço. Todas as operações unidirecionais que passam pelo gateway são mediadas pelo fluxo requestOnly da interface do gateway de serviço; todas as operações solicitação-resposta que passam pelo gateway são mediadas pelo fluxo requestResponse, conforme mostrado na Figura 1.

   Para se adequar a diferentes solicitantes, o gateway de serviço dá suporte aos seguintes protocolos: Web service, HTTP, JMS, e MQ. Quando uma solicitação de serviço entra no gateway de serviço, ela é convertida em um objeto comercial específico de protocolo pela vinculação de dados específicos de protocolo ou manipulador de dados do gateway. Por exemplo, uma solicitação SOAP é agrupada em um objeto comercial TextBody, que é então colocado dentro do corpo do Service Message Object (SMO). O seletor de função específica de protocolo do gateway determina se a solicitação será mediada pelo fluxo requestOnly ou requestResponse. Para maiores informações sobre conversão de dados e seletor de função, consulte o documento Service Gateway Support na seção Recursos deste artigo.

2. Executa o processamento comum em todas as mensagens de solicitação e resposta

   O gateway de serviço dá suporte a login de mensagem, seja gravando as mensagens em uma base de dados, emitindo as mensagens como eventos para um servidor de eventos, ou processando as mensagens com o uso do código personalizado Java. Além disso, é possível adicionar capacidades para realizar ações tais como verificações de segurança e validação.

3. Executa o roteamento de solicitações a provedores de serviço

   O fluxo de mediação processa as solicitações que o gateway de serviço recebe. Após o processamento normal ser realizado na solicitação, ele é roteado para um provedor de serviço. A vinculação de dados específicos de protocolo ou manuseador de dados converte a solicitação do formato de objeto comercial específico de protocolo de volta para o formato de mensagem original. Usando o exemplo anterior, a solicitação é convertida de TextBody de volta para SOAP. O endereço de terminal do provedor de serviço pode ser selecionado dinamicamente na ocasião da operação, ou definido na ocasião do desenvolvimento. Para uma solicitação SOAP, as informações de roteamento podem estar no título SOAP, que geralmente contém informações suficientes para o gateway de serviço determinar o provedor de serviço apropriado, ou podem estar no atributo SOAPAction, na URL, ou na seção WS-Addressing da solicitação.

Se o terminal do provedor de serviço for determinado na ocasião de operação, o gateway de serviço é conhecido como gateway de serviço dinâmico (mostrado na Figura 2), o que significa o suporte de diferentes formas de observar o terminal do provedor de serviço na ocasião da operação, tais como recuperação do endereço de terminal do WebSphere Service Registry and Repository ou de uma base de dados. Um gateway de serviço dinâmico roteia tipicamente as solicitações para o provedor de serviço selecionado 'no estado'.

Se o terminal do provedor de serviço for determinado na ocasião do desenvolvimento, o gateway de serviço é conhecido com um gateway de serviço estático (mostrado na Figura 3). Cada nó de saída de chamada representa um provedor de serviço cujo endereço terminal é definido na respectiva importação no diagrama de montagem. O gateway transforma a solicitação do formato específico de protocolo para o formato definido pela interface do provedor de serviço. Opcionalmente, o gateway de serviço pode enriquecer a solicitação transformada antes de roteá-la ao provedor de serviço.

Para decidir se é preciso um gateway de serviço dinâmico ou um gateway de serviço estático, determine se deseja enriquecer ou transformar sua mensagem de solicitação antes de roteá-la ao provedor de serviço e se mais provedores de serviço podem ser adicionados após o gateway ser implementado. Para enriquecer sua mensagem de solicitação, é preciso usar um gateway de serviço estático. Para adicionar provedores de serviço após a implementação do gateway, use um gateway de serviço dinâmico, pois é possível adicionar provedores de serviço sem atualizar e reimplementar o gateway. Se você utilizar um gateway de serviço estático e desejar adicionar provedores de serviço, será necessário atualizá-lo com as interfaces adicionais do provedor de serviço e reimplementá-lo. Observe que o processamento comum, como login, está disponível independente da escolha do tipo de gateway.

Voltar para parte superior

Resumo

A lista a seguir mostra os benefícios de um gateway de serviço:

• Fornece um único ponto de acesso simples a diversos provedores de serviço, disponibilizando uma única interface genérica de gateway de serviço (ServiceGateway.wsdl).
• Centraliza o processamento comum, tais como login e validação para todas as mensagens de solicitação e resposta, eliminando a necessidade de repetir o desenvolvimento desse processamento entre cada solicitante e provedor.
• Fornece flexibilidade no roteamento de solicitações a diferentes provedores de serviço.

A tabela a seguir resume e contrasta as principais características e funções dos gateways de serviço dinâmico e estático

Agora, que você tem uma visão geral de um gateway de serviço, vamos passar à forma de configuração do gateway para fornecer as funções descritas anteriormente.

Voltar para parte superior

Configurando um gateway de serviço

Para criar um módulo de gateway de serviço em sua área de trabalho que possa funcionar no WebSphere Enterprise Service Bus ou WebSphere Process Server, clique em New > Service Gateway (mostrado na Figura 4) ou New > From Patterns (mostrado na Figura 5).

Após clicar em Next, informe um nome para o módulo de gateway de serviço que será criado em sua área de trabalho. Na próxima página, é possível escolher entre criar um gateway de serviço dinâmico ou um gateway de serviço estático.

As próximas duas seções descrevem as opções de configuração de um gateway de serviço estático e um gateway de serviço dinâmico, respectivamente. O tipo de gateway que escolher, estático ou dinâmico, determina quais informações precisarão ser inseridas no assistente New Service Gateway.

Voltar para parte superior

Gateway de serviço estático

A Figura 7 mostra a segunda página do assistente visualizada ao selecionar estático como o tipo de gateway de serviço.

Para adicionar interfaces de provedor de serviço, clique em Add. É possível selecionar quaisquer interfaces de provedor de serviço que estejam em bibliotecas. O assistente New Service Gateway adiciona automaticamente uma dependência do módulo de gateway de serviço para a biblioteca de cada interface que adicionou.

No mesmo assistente, também é possível registrar as mensagem ou emiti-las como eventos, selecionando Registrar mensagens em uma base de dados, Registrar mensagens usando Java personalizado, ou Emitir mensagens como eventos de base comum a um servidor CEI (mostrado na Figura 7).

Selecionando o protocolo de gateway de serviço do gateway de serviço estático

A Figura 8 mostra cada um dos protocolos de transporte de gateway de serviço que você selecionar. Ao criar um gateway estático, também é necessário selecionar o formato de dados específicos de protocolo da solicitação, tais como XML do protocolo de Serviços Web. Considerando essas informações de formato de dados específicos de protocolo, a vinculação de dados de gateway de serviço ou manipulador de dados pode agrupar o corpo de solicitação como um objeto comercial, tal como TextBody. Para maiores detalhes sobre formato de dados específico de protocolo, consulte o documento Service Gateway Support na seção Recursos deste artigo.

Ao clicar em Finalizar, é gerado o módulo do gateway de serviço.

Voltar para parte superior

Gateway de serviço dinâmico

Para impedir que um gateway de serviço tenha que estar associado a um conjunto fixo de interfaces de serviços, é possível construí-lo independentemente dos serviços que podem ser acessados através dele, atualmente ou no futuro. Quando o gateway estiver funcionando em um servidor, é possível observar qual serviço deve ser chamado com base na solicitação de serviço. Por exemplo, é possível publicar uma URL de endereço de serviço Web externa como

http://mycompany.com:9080/GatewayWeb/sca/GatewayModule?targetService=InsQuote

em que o nome do serviço é um parâmetro, mas o endereço real é

http://internal.mycompany.com:9080/InsuranceQuoteService/InsuranceQuoteHttpService

Quando chega uma solicitação de serviço no gateway, a busca de InsQuote pode ser feita usando uma base de dados ou o WebSphere Service Registry and Repository para determinar qual é o endereço real. Se o endereço real mudar, então é necessário atualizar apenas a base de dados ou repositório. Você verá um exemplo da necessidade de atualizar apenas uma base de dados na seção de exercício deste artigo, em que o gateway usa o endereço real para rotear a chamada de serviço.

A Figura 9 mostra a segunda página do assistente New Service Gateway quando foi escolhido um gateway dinâmico na primeira página. Comparando esta segunda página com a segunda página na Figura 7, observe que não você não associa interfaces específicas de serviço ao gateway de serviço.

Vamos dar uma olhada no que será criado para cada escolha de como o provedor de serviço é selecionado na ocasião de operação.

Selecionar Consultar um WebSphere Service Registry and Repository (WSRR) cria um primitivo de Busca de Terminal que deve ser configurado para conectar ao WebSphere Service Registry and Repository para buscar o endereço de terminal. O endereço de terminal recuperado é armazenado no valor SMO /headers/SMOHeader/Target/address.

Selecionar Recuperar da base de dados cria um primitivo de Busca de Base de Dados que precisa ser configurado para conectar a uma base de dados para buscar o endereço de terminal. O endereço de terminal recuperado será armazenado em /headers/SMOHeader/Target/address.

Se desejar o seu próprio modo de selecionar um serviço, escolha Gravar minha própria lógica. Isto cria um primitivo de mediação personalizado em que é possível gravar código Java ou usar Visual Java para definir o endereço de terminal, de modo que o roteamento ocorrerá dinamicamente.

Finalmente, selecionar Usar um elemento a partir da mensagem de solicitação cria um primitivo Definidor de Elemento de Mensagem no fluxo de mediação. No exemplo mostrado na Figura 10, o primitivo Definidor de Elemento de Mensagem nomeado de RouteMessage copia tudo após ?targetService= na URL de endereço de serviço Web para o endereço de terminal no título SMO.

Por exemplo, um cliente pode enviar uma solicitação ao gateway usando a URL http://localhost:9080/DynamicGatewayModuleWeb/sca/DynamicGatewayModuleExport?targetService=http://localhost:9080/InsuranceQuoteService/InsuranceQuoteHttpService. O nó RouteMessage copiaria http://localhost:9080/InsuranceQuoteService/InsuranceQuoteHttpService para o endereço alvo SMO.

Neste caso, o nó de saída de chamada na mediação usa o endereço alvo para chamar o serviço.

Selecionando o protocolo de gateway de serviço do gateway de serviço dinâmico

A próxima fase é selecionar o protocolo de gateway de serviço. A página do assistente (Figura 11) é muito similar à Figura 8, porém sem a escolha do formado de dados específicos de protocolo. Um gateway de serviço dinâmico não está previsto para acessar nem modificar o corpo da mensagem, pois o roteamento confia apenas no título da solicitação; portanto, não é necessária uma escolha do formato de dados específicos de protocolo.

Ao concluir o assistente, é gerado o módulo de gateway de serviço dinâmico.

Voltar para parte superior

Colocando tudo junto em um exemplo

Agora, que você já viu o básico sobre o uso do padrão Service Gateway, segue um cenário em que é possível tentar criar seu próprio gateway de serviço e vê-lo em ação. Imagine que você tenha cinco serviços Web e, agora, queira registrar cada solicitação aos serviços Web usando um gateway de serviço. Na seção Downloads deste artigo, há um link para o arquivo de intercâmbio de projeto que contém cinco serviços Web. Há também um link para um processo comercial que está ligado às importações de serviço Web. Cada importação possui seu terminal definido no módulo de gateway de serviço prestes a construir.

No início da seção Dynamic Service Gateway, explicamos como adicionar o nome do serviço como um parâmetro à URL de gateway. Alternativamente, seria possível passar o nome do serviço ao gateway, usando um título SOAP, que é aquilo que será mostrado neste exemplo. O gateway usará o nome de serviço para determinar o serviço real a chamar. Você iniciar implementando o aplicativo ClipsAndTacks, que contém o processo Order Handling, e os módulos de serviço Web a um servidor. A seguir, você construirá o gateway que apresenta os módulos ao mundo (mas apenas na forma em que queremos que o mundo os veja).

Consta aqui uma visão geral da arquitetura do cenário e da forma de operação.

1. O cliente de teste emite uma solicitação para fazer um pedido com o processo Order Handling.
2. O processo Order Handling possui lógica comercial que usa os serviços Web ilustrados no lado direito do diagrama.
3. Surge um novo requisito para registrar cada solicitação aos serviços Web. O gateway interage com o processo Order Handling para rotear dinamicamente e mapear as solicitações aos serviços Web.

Nesse cenário, construiremos a parte de serviços Manuseio de Pedido (ou seja, o gateway de serviço) do diagrama. As outras partes do exemplo estão fornecidas em um arquivo de intercâmbio de projeto que será importado ao WebSphere Integration Developer V6.2

1. Vá até a seção Downloads deste artigo e salve o arquivo OrderHandlingService.zip em um local conveniente.
2. Importe o arquivo de intercâmbio de projeto OrderHandlingService.zip para um novo espaço de trabalho do WebSphere Integration Developer.
3. Altere para a visualização Servidores, inicie o WebSphere Process Server e, em seguida, implemente os módulos que estão agora no seu espaço de trabalho ao servidor.

Após importar o arquivo de intercâmbio de projeto, será possível ver os módulos em seu espaço de trabalho como mostra a Figura 13. Observe que também há uma biblioteca de recursos; ela contém somente aqueles arquivos que serão usados para realizar a busca de encaminhamento e para teste.

O módulo ClipsAndTacksF1 contém a lógica de negócios Manuseio de Pedido. Como pode-se reconhecer, os módulos restantes representam os serviços Web mencionados anteriormente.

Cria-se um gateway de serviço dinâmico, portanto, não é preciso especificar as cinco interfaces dos serviços na ocasião do desenvolvimento.

1. Na perspectiva Integração de Negócios, selecione Arquivo > Novo > Gateway de Serviço. É aberto o assistente do Novo Gateway de Serviço.
2. No gateway de serviço, nomeie campo, digite OrderHandlingServices.

3. Clique em Próximo.

Conforme mencionado anteriormente, um gateway dinâmico significa que é necessário buscar o endereço de serviço na ocasião da execução. Para visualizar seu funcionamento, é preciso registrar sua própria lógica personalizada no gateway que simulará a realização de uma busca de base de dados ou repositório.

1. Em Selecionar o tipo de página de gateway, deixe Dinâmico selecionado, e, em seguida, clique emPróximo.
2. Selecione Registrar minha própria lógica. Isso criará um primitivo de mediação personalizada denominado RouteMessage no fluxo de mediação. Crie sua própria lógica dentro desse nó de forma breve.
3. Selecione Mensagens de log usando o Custom Java. Quando o aplicativo estiver em execução, um arquivo de log chamado MessageLog.log será criado no diretório definido pelo ambiente TEMP variável. É possível determinar esse diretório em Microsoft Windows, digitandodefinir temp em um prompt de comando).

4. Clique em Próximo. Selecione Serviço Web (SOAP 1.2/HTTP).

5. Clique em Finalizar.

É criado um módulo de mediação chamado OrderHandlingServices, como mostra a Figura 18. Os próximos passos concluirão a lógica do gateway de serviço.

1. No diagrama assembly, clique em OrderHandlingServices para abri-lo no editor de Fluxo de Mediação.
2. Clique na operação de fonte requestResponse, pois, nesse exemplo, todas as mensagens são mensagens de solicitação-resposta.

A Figura 19 mostra o módulo de mediação do gateway de serviço criado ao concluir o assistente. O nó LogMessage está ali porque você decidiu registrar as mensagens usando custom Java (vide Figura 16). Veja a observação TODO na Figura 19, que indica que é preciso fornecer código Java ou visual no primitivo de mediação personalizada para definir o terminal alvo no XPath /headers/SMOHeader/Target/address. Realize os seguintes passos para concluir essa tarefa:

1. Dê um clique duplo no nó de mediação personalizada RouteMessage para abrir a visualização Propriedades para concluí-la.
2. Clique na guia Importações Java e copie as seguintes linhas:

import commonj.sdo.DataObject;
import com.ibm.websphere.sibx.smobo.TargetAddressType;
import com.ibm.websphere.sibx.smobo.ServiceMessageObjectFactory;
import com.ibm.websphere.sibx.smobo.SOAPHeaderType;
import java.io.File;
import java.util.Scanner;
import java.io.FileNotFoundException

As importações são adicionadas, de modo que os nomes inseridos no código Java RouteMessage não exijam qualificadores.

3. Clique na guia Detalhes e, no lugar da linha abaixo do comentário gerado, out.fire(smo), cole o seguinte código Java:

	//
	// Obtenha o nome do serviço solicitado a partir do cabeçalho SOAP na
	// mensagem enviada a este gateway de serviço.
	//
	SOAPHeaderType soapHeaderType = 
		(SOAPHeaderType)smo.getHeaders().getSOAPHeader().get(0);
	DataObject soapHeaderValue = (DataObject)soapHeaderType.getValue();
	String reqServiceName = soapHeaderValue.getString("targetService");
	System.out.println("->Gateway service request for: " + reqServiceName);
	//
	// Leia o arquivo de texto para determinar o mapeamento entre 
	// os pontos finais e os nomes de serviço.
	//
	// NOTA: Modifique o nome do arquivo dependendo do 
	// local atual do arquivo.
	//
	File dbFile = new File("D:\\ServicesDB.txt");
	Scanner fileScanner;
	try {
	 fileScanner = new Scanner(dbFile);
	} catch (FileNotFoundException e) {
	 e.printStackTrace();
	 return;
	}
	try {
	 while (fileScanner.hasNextLine()) {
	  // 
	  // Leia cada linha no arquivo para obter o mapeamento entre
	  // o nome do serviço solicitado e o ponto final atual.
	  // As linhas estão no formato <service name>=<service URL>
	  //
	  String nameUrlLine = fileScanner.nextLine();
	  Scanner nameUrlScanner = new Scanner(nameUrlLine);
	  nameUrlScanner.useDelimiter("=");
	  if (nameUrlScanner.hasNext()) {
	   String serviceName = nameUrlScanner.next();
	   String serviceURL = nameUrlScanner.next();
	   if (serviceName.equals(reqServiceName)) {
	    //
	    // Encontramos o nome de serviço solicitado correspondente no 
	    // arquivo de texto. Configure o endereço de ponto final atual.
	    //
	    System.out.println("Routing " + reqServiceName + " to "
	      + serviceURL);
	    TargetAddressType targetAddress = 
	      ServiceMessageObjectFactory.eINSTANCE
	      .createTargetAddressType();
	    targetAddress.setAddress(serviceURL);
	    smo.getHeaders().getSMOHeader().setTarget(targetAddress);
	   }
	  }
	  nameUrlScanner.close();
	 }
	} finally {
	 fileScanner.close();
	}
	//
	// Propague o objeto da mensagem de serviço ao  
	// primitivo que está cabeado até o terminal 'externo'.
	//
	out.fire(smo);

4. Salve todos os editores no espaço de trabalho

Para que esse código encaminhe solicitações de serviço, ele precisa de uma base de dados (no nosso caso, seria um arquivo de texto) que determina o serviço correto para executar cada solicitação recebida. Esse código de exemplo espera que o conteúdo do arquivo esteja em D:\ServicesDB.txt, embora seja possível alterar isso, se você desejar colocá-lo em outro lugar (como se estivesse sendo executado no Linux) e modificar o passo 2 abaixo da forma correspondente.

1. No sistema de arquivo, navegue ao projeto Recursos que foi importado com o arquivo de intercâmbio de projeto e localize o arquivo ServicesDB.txt.
2. Copie ServicesDB.txt à raiz de seu drive D: ou a qualquer local especificado em seu código.

Lembre-se que o nome de serviço será passado ao gateway, usando um cabeçalho SOAP. Os próximos passos fornecem uma definição para o cabeçalho, de modo que o módulo de mediação de gateway de serviço a compreenderá.

1. Na biblioteca Recursos, na pasta Tipos de Dados, localize o objeto de negócio TargetServiceHeaderType.
2. Copie TargetServiceHeaderType ao módulo OrderHandlingServices. TargetServiceHeaderType será listado em Tipos de Dados nesse módulo.
3. Implemente o módulo OrderHandlingServices ao servidor.

É construído o gateway de serviço. À medida que você adicionar ou remover serviços, ou alterar os terminais de serviço, altere apenas a base de dados ou repositório ou, como nesse exemplo, o arquivo ServicesDB.txt. O módulo OrderHandlingServices não exigirá alterações.

Agora você está pronto para testar seu aplicativo.

1. Na visualização Integração de Negócios, clique com o botão direito em ClipsAndTacksF1 e selecione Teste > Módulo de Teste. É aberto o cliente de teste de integração.
2. Selecione a guia Configurações clique com o botão direito em Emuladores de Tarefa Humanae, em seguida, selecione Adicionar > Emulador de Tarefa Humana. Há uma tarefa humana que implementa a atividade Enviar Pedido ao Cliente no processo de negócios. Portanto, é possível usar o emulador de tarefa humana para reivindicar e concluir a tarefa, usando o cliente de teste de integração.
3. Clique em Próximo, clique em Selecionar Tudoe, em seguida, clique em Finalizar para criar o emulador de tarefa humana.
4. No cliente de teste de integração, selecione a guia Eventos. Para o componente, selecione OrderHandling e, na coluna Valor na linha CustomerNumber, digite 123.
5. Para executar o teste, pressione Ctrl-R. Se a janela de Login de Usuário abrir, insira seu ID e senha de usuário de servidor e, em seguida, clique em OK.
6. Aguarde o evento de Reivindicação (OrderHandling.ShipOrdertoCustomer_InputCriterion) ser exibido. Lembre-se de que você definiu o emulador de tarefa humana; portanto, quando esse evento for exibido para a atividade Enviar Pedido ao Cliente, você vai querer simular os dados retornados pela tarefa humana. Para fazê-lo, em Inserir parâmetros, clique com o botão direito em Pedido e selecione Copiar Valor. Se necessário, desça com o mouse até Inserir parâmetros, clique com o botão direito em Pedido e selecione Colar Valor.
7. Para continuar a execução do teste, pressione Ctrl-R e, em seguida, aguarde a conclusão do aplicativo.

A Figura 21 mostra a execução completa do aplicativo. Esse teste é definido para percorrer um caminho particular através do processo de negócios, porém o foco desse exercício está nas chamadas de saída do processo de negócios ao gateway de serviço. As chamadas de saída do processo Manuseio de Pedido são as importações de serviço Web que mencionamos no início do exercício. Se você mudar para a visualização Logs de Servidor, você verá entradas de log do gateway de onde elas encaminharam cada chamada para um serviço específico.

Você escolheu as mensagens de log que passam pelo gateway de serviço. Portanto, uma rápida verificação do arquivo de log <local TEMP>/MessageLog.mostrará entradas, como mostra a Figura 22.

Voltar para parte superior

Testando somente o módulo de gateway de serviço

Você concluiu o teste de seu aplicativo que invocou seus serviços através do gateway de serviço. Essa seção final lhe mostrará como é possível a própria unidade testar o gateway. Nesse caso, você enviará uma mensagem diretamente ao gateway de serviço, que fará com que o gateway de serviço encaminhe a mensagem a um dos serviços Web.

1. Na visualização Integração de Negócios, clique com o botão direito no módulo OrderHandlingServices e selecione Teste > Módulo de Teste.
2. Para o componente, selecione OrderHandlingServicesExport e, para a operação, selecione requestResponse, como mostra a Figura 23.

3. Selecione a guia Mensagem e selecione Editor XML .
4. Clique em Importar Mensagem, navegue ao projeto Recursos no espaço de trabalho, selecione Input_CheckOrderHandlingPolicyForAutomaticApproval.xmle, em seguida, clique em Abrir. São exibidos os conteúdos do editor XML, como mostra a Figura 24.

5. Para executar o teste, pressione Ctrl-R. O gateway encaminhará a solicitação individual e criará uma entrada no log do servidor, como mostra a Figura 25.

Voltar para parte superior

Resumo

Aqui está o que você realizou nesse tutorial:

• Você importou cinco serviços Web e um processo Manuseio de Pedido para o seu espaço de trabalho e os implementou a um ambiente de teste de unidade do WebSphere Process Server.
• Usando o assistente de Padrão de Gateway de Serviço, você criou um gateway de serviço dinâmico (chamado OrderHandlingServices), que encaminha solicitações do processo Manuseio de Pedido a todos os serviços Web. Visto que o gateway OrderHandlingServices é dinâmico, não foi preciso especificar as interfaces dos serviços Web quando o gateway foi criado. Além disso, o gateway realiza as seguintes ações:
  • Seleciona qual serviço Web executar, usando uma lógica personalizada. A lógica personalizada faz com que o nome de serviço solicitado no cabeçalho SOAP busque pelo endereço de terminal real em um arquivo. O campo /headers/SMOHeader/Target/address é, então, definido com o endereço de terminal real.
  • Registra todas as solicitações aos serviços Web.
• Você testou o gateway de serviço, testando o componente de processo Manuseio de Pedido, e o gateway de serviço usando diretamente a mensagem de SOAP CheckOrderHandlingPolicyForAutomaticApproval.

Voltar para parte superior

Conclusão

Neste artigo, você aprendeu sobre as funções e benefícios de um gateway de serviço e criou e testou um gateway de serviço dinâmico para executar um conjunto de serviços Web a partir de um processo de negócios. O gateway serve como um ponto de entrada individual aos serviços para o processo de negócios, bem como a qualquer outro cliente que deva acessar o mesmo conjunto de serviços. O gateway também fornece processamento comum para as mensagens de solicitação e resposta e encaminha cada solicitação ao provedor de serviço adequado. Lembre-se, o que você criou com o assistente de gateway de serviço é apenas um ponto de partida; ele determina o que existirá inicialmente no módulo de mediação que você cria usando o assistente Novo Gateway de Serviço. Após ter concluído o assistente, é possível personalizar o fluxo de mediação (especificamente, as funções do gateway de serviço) para fazer quase qualquer coisa.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

• O que há de novo no IBM WebSphere Enterprise Service Bus V6.2: O suporte de gateway de serviço fornece uma descrição técnica detalhada do suporte de gateway de serviço no WebSphere Integration Developer e no WebSphere Enterprise Service Bus V6.2.
  
  
• O centro de informações do WebSphere Integration Developer V6.2 descreve o gateway de serviço. Selecione WebSphere Integration Developer, Versão 6.2.0> Referência > Primitivos de mediação > Lista de primitivos de mediação > Primitivo de mediação de Registrador de Mensagem.
  
  
• O centro de informações do WebSphere Integration Developer V6.2 descreve o primitivo de mediação do Registrador de Mensagem. Selecione WebSphere Integration Developer, Versão 6.2.0 > Cenários > Criando um gateway de serviço.
  
  

Sobre os autores

Voltar para parte superior

Marcas Registradas  |  Termos e condições do My developerWorks

Índice

• Introdução
• Resumo
• Configurando um gateway de serviço
• Gateway de serviço estático
• Gateway de serviço dinâmico
• Colocando tudo junto em um exemplo
• Testando somente o módulo de gateway de serviço
• Resumo
• Conclusão
• Download
• Recursos
• Sobre os autores
• Comentários