O Intermediário Implementa um Novo Serviço da Web - Detalhe

Esta é uma visão geral de um cenário típico de ponta a ponta em que 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.

Há um mecanismo para que o intermediário chame operações no sistema existente (ou seja, o sistema expõe uma interface para o intermediário). Geralmente, o sistema existente seria ativado para o WebSphere MQ, significando que ele recebe mensagens do MQ contendo dados do aplicativo, despacha-as para a implementação subjacente e, em seguida, compacta os valores de retorno como uma resposta do MQ. As estruturas de dados fornecidas e retornadas por essas operações existentes estão definidas em um arquivo de cabeçalho C ou copybook COBOL.

O serviço da Web serve para oferecer uma interface baseada nas operações já expostas pelo sistema existente. Esta interface pode incluir todas as operações existentes, algum subconjunto delas e/ou operações compostas.

Para definir sua interface:
  1. Examine 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 isso deve ser representado na interface (como muitas operações diferentes ou como poucas operações com várias finalidades)
Uma decisão básica é se a interface de serviço da Web terá o estilo de RPC ou o estilo de documento. (Consulte Serviços da Web, WSDL e Fluxos de Mensagens e Relacionamento do WSDL com o Modelo de Mensagem).
  • Uma interface de estilo de RPC geralmente é projetada para ser mapeada para um conjunto subjacente de operações fornecidas por alguma API, e as operações individuais (chamadas de métodos) possuem cargas úteis relativamente pequenas.
  • Uma interface de estilo de documento pode ter poucas operações, cada uma com uma carga útil maior - por exemplo, este pode ser um documento que representa um pedido de empréstimo.
O WS-I (consulte http://www.ws-i.org/) recomenda a utilização apenas do WSDL de estilo de documento, mas muitos serviços da Web antigos utilizam o estilo de 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á necessário fazer o importador criar os elementos globais requeridos no modelo do intermediário. O WS-I recomenda que a carga útil do 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.

    Neste estágio, você tem um modelo de mensagem para os dados a serem utilizados ao chamar 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). (Consulte Trabalhando com um Arquivo de Categoria de Mensagens)
    • Se você escolher o WSDL de estilo de documento, o próprio conjunto de mensagens não será modificado.
    • Se você escolher WSDL estilo de RPC, as mensagens correspondentes ao pedido e à resposta para cada operação WSDL serão criadas e incluídas no conjunto de mensagens automaticamente
  3. A etapa de geração de WSDL resultará na inclusão automática do SOAP mxsds (arquivos de definição de mensagem) no conjunto de mensagens. Especificamente, isto inclui o envelope SOAP mxsd e (se o estilo WSDL for RPC-encoded) a codificação SOAP mxsd.
  4. Se estiver criando um novo cliente de serviços da Web, utilize o WSDL gerado com a tecnologia do cliente de serviços da Web escolhida. Isso é feito com uma ferramenta diferente do WebSphere Message Broker, por exemplo, o 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 nós do nó de extremidade são HTTP ou MQ, dependendo do transporte utilizado pelo cliente. As propriedades do nó input são:
    • domínio: "MRM"
    • conjunto: o conjunto de mensagens que contém a definição de Envelope SOAP
    • tipo: "Envelope"
    • formato "XML1"
  6. Quando chamado pelo fluxo, o analisador cria uma árvore lógica que inclui o envelope SOAP conforme definido pelo SOAP mxsd pré-gravado. 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. Aplique a validação no nó input, se necessário.

    Neste estágio, você tem uma árvore lógica, mas não sabe qual carga útil SOAP foi recebida. Você pode verificar o campo HTTP SOAPAction/action para determinar o provável conteúdo, mas isto 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 ter uma única definição de mapeamento com as mensagens message1a e message1b mapeadas para a mesma message2 de destino.
    Como alternativa, podem ser fornecidos 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 o usuário precisa determinar qual carga útil ele recebeu antes de aplicar o mapeamento. Isto pode ser feito no ESQL da seguinte forma:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = ‘foo’) ...
     
    ou utilizando uma referência de campo, por exemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = “foo”) ...
     
    Depois disso, agora que o conteúdo é conhecido, o fluxo pode ser ramificado apropriadamente (por exemplo, utilizando o nó RouteToLabel) com cada ramificação tendo nós Mapping e/ou Compute específicos do conteúdo. Para fluxos simples, toda a lógica pode ser mantida em um único nó Compute, se necessário.

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

Para obter um cenário semelhante, consulte a amostra: Amostra Web Service Host.

Conceitos relacionados
Serviços da Web, WSDL e Fluxos de Mensagens
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
O Intermediário Implementa Interface Não do Serviço da Web para Novo Serviço da Web
Tarefas relacionadas
O Intermediário Implementa uma Interface de Serviço da Web Existente - Detalhe
O Intermediário Chama um Serviço da Web Existente - Detalhe
Avisos | Marcas Registradas | Downloads | Biblioteca | Suporte | Feedback
Direitos Autorais IBM Corporation 1999, 2006 Última Atualização: 1 Sep 2006
ac34570_