Detalhe de como o Intermediário Implementa uma Interface de Serviço da Web Existente

Saiba sobre um cenário típico de ponta a ponta no qual você tem um cliente de serviço da Web e deseja que o intermediário disponibilize para ele alguma funcionalidade não de 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.

Como no exemplo anterior (Detalhes de como o Intermediário Implementa um Novo Serviço da Web), existe algum mecanismo para o intermediário chamar 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 WebSphere MQ. As estruturas de dados fornecidas e retornadas por estas operações existentes estão definidas em um arquivo de cabeçalho C ou copybook COBOL.

No entanto, neste exemplo, o serviço da Web é restrito no que ele deve fornecer, porque a definição WSDL para o cliente de serviço da Web já existe.

Um possível cenário pode ser que um cliente de serviços da Web amplamente distribuído já conceda os usuários acesso a um recurso de negócios específico, e a função do intermediário é oferecer a mesma interface para uma nova implementação baseada no sistema existente. Talvez o provedor de serviços da Web original oferece uma qualidade de serviço diferente, ou seja descontinuado por alguma razão.

Como anteriormente, o intermediário pode chamar a função do sistema existente utilizando o WebSphere MQ.

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 Web Services Interoperability Organization (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. Importe o arquivo WSDL existente para criar um modelo de mensagem apropriado para dos documentos da instância esperados (consulte Importando Estruturas de Dados). O fluxo analisa o pedido SOAP correspondente e deve transformar-se em e a partir do formato de dados existente necessário. É possível inspecionar as definições de mensagem importadas e utilizar os editores ESQL ou de Mapeamento para ajudar a criar o fluxo. Você não cria arquivos de categoria ou gera WSDL a partir do modelo do intermediário.
  3. A etapa de importação WSDL resulta nos arquivos mxsd SOAP apropriados sendo automaticamente incluídos no conjunto de mensagens. Especificamente, a importação inclui o arquivo mxsd do envelope SOAP e, se necessário, o arquivo mxsd de codificação SOAP.
  4. 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
  5. Quando chamado pelo fluxo, o analisador cria uma árvore lógica que inclui o envelope SOAP conforme definido pelo arquivo mxsd SOAP fornecido. 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).

  6. Você pode fornecer mapeamento único das mensagens de carga útil permitidas para as mensagens requeridas do sistema existente. Por exemplo, uma única definição de mapeamento pode mapear mensagens message1a e message1b para o mesmo destino message2.
    Como alternativa, podem ser fornecidos mapeamentos separados para cada tipo de mensagem, ou para grupos de tipos de mensagens 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 aplicar o mapeamento. É possível codificar ESQL da seguinte forma:
     
     DECLARE SOAPENV NAMESPACE 'http://schemas.xmlsoap.org/soap/envelope/';
     SET contentType = FIELDNAME(InputBody.SOAPENV:Body.*[<]);
     IF (contentType = 'foo') ...
     
    ou utilize uma referência de campo, por exemplo:
     
     DECLARE R REFERENCE TO InputRoot.MRM.SOAPENV:Body.*[<];
     IF (FIELDNAME(R) = "foo") ...
     
    Quando o conteúdo for conhecido, o fluxo poderá ser ramificado apropriadamente (por exemplo, utilizando um nó RouteToLabel) com cada ramificação tendo nós Mapeamento, nós Compute específicos de conteúdo, ou ambos. Para fluxos simples, você pode codificar toda a lógica em um único nó Compute, se necessário.

    Agora chame o sistema existente (geralmente por meio do WebSphere MQ), recupere a resposta esperada e propague a resposta do serviço da Web. Este cenário é semelhante ao descrito em Detalhes de como o Intermediário Implementa um Novo Serviço da Web, exceto que o fluxo de mensagens também deve ser mapeado entre o formato de dados utilizado pelo cliente de serviço da Web e o formato utilizado pelo sistema existente ativado para WebSphere MQ. 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.

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
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
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

ac34580_