Detalhes de como o Intermediário Implementa um Novo Serviço da Web

Saiba sobre um cenário típico de ponta a ponta no qual o intermediário implementa um serviço da Web.

Um sistema baseado em C ou COBOL existente oferece alguma lógica de negócios que pode ser exposta de forma útil como um serviço da Web.

O intermediário pode iniciar a operação no sistema existente, ou seja, o sistema expõe uma interface para o intermediário. Geralmente, o sistema existente é ativado para o WebSphere MQ; ele recebe mensagens do WebSphere MQ contendo dados do aplicativo, despacha-as para implementação subjacente e, em seguida, compacta os valores de retorno como uma resposta do WebSphere MQ. As estruturas de dados fornecidas para e retornadas por estas operações existentes são definidas em um arquivo de cabeçalho C ou copybook COBOL.

O serviço da Web oferece uma interface baseada nas operações já expostas pelo sistema existente. Esta interface pode incluir todas as operações existentes, ou um subconjunto das operações existentes ou operações compostas, ou de ambas.

Para definir sua interface:
  1. Consulte a função de negócios oferecida pelo sistema existente.
  2. Selecione o subconjunto desta função de negócios a ser exposta.
  3. Decida como representar o subconjunto na interface, ou seja, como muitas operações diferentes ou como poucas operações de várias finalidades.
É necessário decidir se deseja que a interface de serviço da Web tenha o estilo RPC ou estilo de documento. Para obter informações adicionais sobre serviços da Web, fluxos WSDL e de mensagens, consulte Relacionamento do WSDL com o Modelo de Mensagem.
  • Uma interface de estilo RPC geralmente é projetada para ser mapeada para um conjunto subjacente de operações fornecidas por uma API, e as operações individuais (chamadas de método) possuem cargas úteis relativamente pequenas.
  • Uma interface de estilo de documento pode ter menos operações, cada uma com uma carga útil maior; por exemplo, um documento pode representar um pedido de empréstimo.
O Web Services Interoperability Organization (WS-I) recomenda a utilização apenas de WSDL de estilo de documento, mas muitos serviços da Web mais antigos utilizam o estilo RPC.

Para implementar o cenário:

  1. Importe as estruturas de dados da API existentes, por exemplo, utilizando o importador C. Se o WSDL de estilo de documento for utilizado, será preciso utilizar o assistente do importador para criar os elementos globais necessários no modelo do intermediário. O WS-I recomenda que a carga útil de serviço da Web seja qualificada pelo espaço de nomes, portanto, o usuário deve especificar o espaço de nomes de destino na importação.

    Agora você tem um modelo de mensagem para os dados a serem utilizados para iniciar as operações existentes.

  2. Gere a definição WSDL. A menos que já tenha criado as Categorias de Mensagens requeridas, crie uma Categoria de Mensagem para cada operação de serviços da Web a ser exposta e associe as mensagens do intermediário existentes às funções SOAP apropriadas (entrada, saída ou falha). Para obter mais informações, consulte o manual Trabalhando com um Arquivo de Categoria de Mensagens.
    • Se você escolher WSDL de estilo de documento, o próprio conjunto de mensagens não será modificado.
    • Se você escolher WSDL de estilo RPC, as mensagens correspondentes ao pedido e resposta para cada operação WSDL serão criadas e incluídas automaticamente no conjunto de mensagens.
  3. A etapa de geração de WSDL resultará na inclusão automática de arquivos mxsd SOAP apropriados (arquivos de definição de mensagem), que inclui o arquivo mxsd do envelope SOAP e (se o estilo WSDL contiver codificação RPC) o arquivo mxsd de codificação SOAP, no conjunto de mensagens.
  4. Se desejar criar um novo cliente de serviços da Web, utilize o WSDL gerado com a tecnologia do cliente de serviços da Web escolhida. Utilize uma ferramenta diferente de WebSphere Message Broker; por exemplo, você pode utilizar Rational Application Developer ou .NET.
  5. Implemente um fluxo de mensagens para receber o pedido de serviço da Web, ou seja, para agir como o provedor de serviços da Web. Os conjuntos de terminais são HTTP ou WebSphere MQ, dependendo do transporte utilizado pelo cliente. As propriedades do nó input são:
    • Domínio de Mensagem: MRM
    • Conjunto de Mensagens: o conjunto de mensagens que contém a definição de Envelope SOAP
    • Tipo de Mensagem: Envelope
    • Formato da Mensagem: XML1
  6. Quando o analisador é iniciado pelo fluxo, o analisador cria uma árvore lógica contendo o envelope SOAP conforme definido pelo arquivo mxsd SOAP predeterminado. A análise continua automaticamente nos pontos de conexão no envelope SOAP (corpo e cabeçalho SOAP), tentando a correspondência com outras definições de mensagem no conjunto de mensagens. Você pode aplicar validação no nó input, se necessário.

    Agora você tem uma árvore lógica, mas não sabe qual carga útil SOAP foi recebida. Verifique o campo de ação HTTP SOAPAction para determinar o provável conteúdo, mas esta verificação funciona apenas para HTTP. (A utilização de SOAPAction não é recomendada pelo WS-I).

  7. Você pode fornecer mapeamento das mensagens de carga útil permitidas para as mensagens requeridas do sistema existente. Por exemplo, você pode te uma única definição de mapeamento com as mensagens message1a e message1b mapeadas para a mesma message2 de destino.
    Como alternativa, é possível fornecer mapeamentos separados para cada tipo de mensagem, ou para grupos de tipos de mensagem relacionados. Esta abordagem pode resultar em definições de mapeamento mais gerenciáveis e reutilizáveis. A desvantagem é que você deve determinar qual carga útil foi recebida antes de poder aplicar o mapeamento. É possível determinar qual carga útil foi recebida utilizando ESQL da seguinte forma:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = 'foo') ...
     
    ou é possível utilizar uma referência de campo, por exemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = "foo") ...
     
    Quando tiver determinado a carga útil, você poderá mapear o fluxo para a ramificação de forma apropriada (por exemplo, utilizando um nó RouteToLabel) com cada ramificação tendo um nó Mapeamento específico de conteúdo, um nó Compute ou ambos. Para fluxos simples, você pode codificar toda a lógica em um único nó Compute, se necessário.

    Agora inicie o sistema existente (geralmente por meio do WebSphere MQ), recupere qualquer resposta esperada e propague a resposta do serviço da Web. O designer do fluxo de mensagens deve considerar a possibilidade de que o aplicativo de negócios não envie a resposta esperada em um período de tempo aceitável.

Para um cenário semelhante, consulte a amostra a seguir: Você pode visualizar amostras apenas quando utilizar o centro de informações integrado ao Message Brokers Toolkit.
Conceitos relacionados
Fluxos de Mensagens do Domínio XML
O Intermediário Chama um Serviço da Web Existente
O Intermediário Implementa uma Nova Interface de Serviço da Web
O Intermediário Implementa uma Interface de Serviço da Web Existente
Intermediário Implementa Interface Não do Serviço da Web para Novo Serviço da Web
Relacionamento do WSDL com o Modelo de Mensagem
Tarefas relacionadas
Detalhe de como o Intermediário Implementa uma Interface de Serviço da Web Existente
O Intermediário Chama um Serviço da Web Existente - Detalhe
Trabalhando com um Arquivo de Categoria de Mensagens
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última atualização : 2009-02-13 16:11:57

ac34570_